mbirth/gcd-parser

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

mbirth opened this issue · 1 comments

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.

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