Vector3 firmware has binary header without actual binary data - which is not dumped into RCP file #15

New Issue

2021-05-02T00:46:24+01:00

mbirth commented

2021-05-02 00:46:24 +01:00

(Migrated from github.com)

When fixing #13, I've also noticed something strange: The Vector firmware has a TLV6 and TLV7 block with no actual binary data (Field 2015 - Binary length = 0). Since the actual binary data is absent, the two blocks aren't dumped to the rcp file. The struct looks like this:

Opening Vector3_380.gcd
#000: TLV Type 0001 at 0x8, 1 Byte - Checksum rectifier
#001: TLV Type 0005 at 0xd, 55 Bytes - Copyright notice
#002: TLV Type 0001 at 0x48, 1 Byte - Checksum rectifier
#003: TLV Type 0003 at 0x4d, 2 Bytes - Part number?
#004: TLV Type 0001 at 0x53, 1 Byte - Checksum rectifier
#005: TLV Type 0006 at 0x58, 14 Bytes - Block Type 7 format definition
  - Field list: 1009 100a 2015 2017 2018 2019 5003
#006: TLV Type 0007 at 0x6a, 20 Bytes - Binary descriptor
  - Field 1 (1009):         Device hw_id: 0x0ae3 / 2787 (Vector 3)
  - Field 2 (100a):           Block type: 0x07d0 / 2000
  - Field 3 (2015):        Binary length: 0 Bytes   <---- Zero length = no binary block following?
  - Field 4 (2017):           Field 2017: 0x2ada0 / 175520
  - Field 5 (2018):           Field 2018: 0xb998 / 47512
  - Field 6 (2019):           Field 2019: 0x3a6d0 / 239312
~~~~~~~~~~~ BINARY BLOCK MISSING HERE ~~~~~~~~~~~~~
#007: TLV Type 0001 at 0x82, 1 Byte - Checksum rectifier
#008: TLV Type 0006 at 0x87, 28 Bytes - Block Type 7 format definition
  - Field list: 4007 0020 100a 000c 100d 100e 100f 1010 1011 1012 1013 2015 201a 5003
#009: TLV Type 0007 at 0xa7, 57 Bytes - Binary descriptor

When dumping, the TLV6 and TLV7 are tied to the actual binary data. Since there is none, they're not written to the RCP file. This needs to be refactored so compiling yields the original file.

When fixing #13, I've also noticed something strange: The Vector firmware has a TLV6 and TLV7 block with no actual binary data (Field 2015 - Binary length = 0). Since the actual binary data is absent, the two blocks aren't dumped to the rcp file. The struct looks like this: Opening Vector3_380.gcd #000: TLV Type 0001 at 0x8, 1 Byte - Checksum rectifier #001: TLV Type 0005 at 0xd, 55 Bytes - Copyright notice #002: TLV Type 0001 at 0x48, 1 Byte - Checksum rectifier #003: TLV Type 0003 at 0x4d, 2 Bytes - Part number? #004: TLV Type 0001 at 0x53, 1 Byte - Checksum rectifier #005: TLV Type 0006 at 0x58, 14 Bytes - Block Type 7 format definition - Field list: 1009 100a 2015 2017 2018 2019 5003 #006: TLV Type 0007 at 0x6a, 20 Bytes - Binary descriptor - Field 1 (1009): Device hw_id: 0x0ae3 / 2787 (Vector 3) - Field 2 (100a): Block type: 0x07d0 / 2000 - Field 3 (2015): Binary length: 0 Bytes <---- Zero length = no binary block following? - Field 4 (2017): Field 2017: 0x2ada0 / 175520 - Field 5 (2018): Field 2018: 0xb998 / 47512 - Field 6 (2019): Field 2019: 0x3a6d0 / 239312 ~~~~~~~~~~~ BINARY BLOCK MISSING HERE ~~~~~~~~~~~~~ #007: TLV Type 0001 at 0x82, 1 Byte - Checksum rectifier #008: TLV Type 0006 at 0x87, 28 Bytes - Block Type 7 format definition - Field list: 4007 0020 100a 000c 100d 100e 100f 1010 1011 1012 1013 2015 201a 5003 #009: TLV Type 0007 at 0xa7, 57 Bytes - Binary descriptor When dumping, the TLV6 and TLV7 are tied to the actual binary data. Since there is none, they're not written to the RCP file. This needs to be refactored so compiling yields the original file.

pavlinux commented

2021-05-02 15:50:02 +01:00

(Migrated from github.com)

zero-length array is feature not bug 🤣
https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

zero-length array is feature not bug :rofl: https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mbirth/gcd-parser#15