Problem with the function readBytesTerm in "ByteBufferKaitaiStream.java"

[ranitg]

Hi,

The line:
int c = bb.get();
in the function readBytesTerm in "ByteBufferKaitaiStream.java"

This should read into an unsigned int variable.

In the kaitai web IDE the code works as:
terminator: 0xfe

but in this project:
terminator: -2 (the byte is read as -2 (int) instead of 254 (unsigned int))

This is an inconsistency.

Thanks!

[generalmimon]

Good catch! I came to the conclusion that the signature of method readBytesTerm:

kaitai_struct_java_runtime/src/main/java/io/kaitai/struct/KaitaiStream.java

Line 281 in e1168b0

abstract public byte[] readBytesTerm(int term, boolean includeTerm, boolean consumeTerm, boolean eosError);

should be changed to accept byte in place of the term parameter (not int). It just makes more sense and conveys the intent better - terminator isn't allowed to be anything else than a byte value. In addition, methods for applying the terminator and pad-right properties on already parsed byte arrays (which arise when you use size or size-eos: true) also use the byte type to accept byte values:

kaitai_struct_java_runtime/src/main/java/io/kaitai/struct/KaitaiStream.java

Line 301 in e1168b0

public static byte[] bytesStripRight(byte[] bytes, byte padByte) {

kaitai_struct_java_runtime/src/main/java/io/kaitai/struct/KaitaiStream.java

Line 308 in e1168b0

public static byte[] bytesTerminate(byte[] bytes, byte term, boolean includeTerm) {

On the other hand, the processXor method for a single value uses int for the byte key (which is especially strange because the processXor for a multi-byte key is using byte[]):

kaitai_struct_java_runtime/src/main/java/io/kaitai/struct/KaitaiStream.java

Line 349 in e1168b0

public static byte[] processXor(byte[] data, int key) {

kaitai_struct_java_runtime/src/main/java/io/kaitai/struct/KaitaiStream.java

Line 365 in e1168b0

public static byte[] processXor(byte[] data, byte[] key) {

So I think it's reasonable to normalize everything to use byte everywhere.

There is a question of breaking backward compatibility, since we'll need to adjust the compiler to inject the (byte) 254 type castings (and the generated Java parsers intended for older runtime versions (without the narrowing type conversion) will trigger a compile-time error), but I believe it's not much of an issue - anyone can just grab the latest compiler and update the parser in minutes.