Wrong IFFDataRecord implementation in Java and missing on C++

[Alessio Iannone]

Hi, I'am actually implementing IFFDataPdu for the C++ side and trying to figure out how to deal with the record length attributes when marshalling and unmarshalling I discovered also that this part is wrong in the Java side.
https://github.com/open-dis/open-dis-java/blob/master/src/main/java/edu/nps/moves/dis7/IFFData.java
Specification says that: Record Length—16-bit unsigned integer (6 + K1 + P1) but on the java code i found
dos.writeShort((short) iffData.length);

this should be
dos.writeShort((short)( 6 + iffData.length));

and also no check is performed to assure that the iffData array has been padded in a way to adhere to the 32 bit boundary of the whole record.

At page 281 of the IEEE 1278.1 2012 document it states:

"Record Length. This field shall indicate the record length expressed as the total number of
octets in the record. The value of the Record Length shall be the sum of the sizes of the Record
Type field, the Record Length field, all Record-Specific fields, and any padding required to end
the record on a 32-bit boundary. All Record Length values shall be a multiple of 4. The Record
Length shall be represented by a 16-bit unsigned integer."

So, for me, this means that the whole IFFDataRecord shall be a multiple of 32bit and so due to the fact that recordType and record length are already 6 bytes long the IFFDataRecord shall be of a minimum of 8 bytes long

EDIT:
I have noticed that also the unmarshall is wrong
recordLength = (int) dis.readUnsignedShort(); iffData = new byte[recordLength];
should be something like
recordLength = (int) dis.readUnsignedShort(); iffData = new byte[recordLength-6];
but the specification it's not clear how handle the padding....
What do you think about it? Have you any idea how to find how many bytes are for the data and how many for the padding....
the only things I have found is to differentiate according to the recordtype...each record type has different lengths... most are 16 bit some 128...

Please note, that I'am actually developing the C++ side following this approach