BERTLVPackager throws a java.lang.ArithmeticException: divide by zero

[christopher-grech]

Whenever a tag is specified with a length of zero, rather than the tag getting ignored, the implementation is throwing a divide by zero exception.

Looking through the code, I believe that changing lines 259 - 272 from:

if (length > 0) {
    System.arraycopy(b, consumed, value, 0, value.length);
}

int uninterpretLength = getUninterpretLength(length, valueInterpreter);
byte[] rawValueBytes =
        valueInterpreter.uninterpret(value, 0, uninterpretLength);

tlvSubFieldData = unpackValue(tag, rawValueBytes, subFieldNumber, length);


consumed = consumed + length;
ISOTaggedField tlv = new ISOTaggedField(tag, tlvSubFieldData);
m.set(tlv);

to:

if (length > 0) {
    System.arraycopy(b, consumed, value, 0, value.length);


    int uninterpretLength = getUninterpretLength(length, valueInterpreter);
    byte[] rawValueBytes =
            valueInterpreter.uninterpret(value, 0, uninterpretLength);

    tlvSubFieldData = unpackValue(tag, rawValueBytes, subFieldNumber, length);


    consumed = consumed + length;
    ISOTaggedField tlv = new ISOTaggedField(tag, tlvSubFieldData);
    m.set(tlv);
}

should solve the issue.

The problem here is that both getUninterpretLength() and unpackValue() will fail with this exception, however, there's no need to call them if the data length is indeed zero.

[christopher-grech]

We're currently using version 2.1.3, just in case you'll need that info.

[ar]

Thanks for the bug report and suggested solution.

[christopher-grech]

Happy to help.

[ar]

The Exception is definitely an error, but I believe a zero length tag is still valid and need to be encoded anyway.

[christopher-grech]

Fair enough. So will it be encoded with a null value then?

[ar]

I just added a test for a zero length tag, and it works OK. Perhaps you can run it there
(gradle test --tests=BERTLVPackagerTest --info) and eventually provide an example of a failing test that produces your exception so we can get our arms around the problem.

[christopher-grech]

Awesome! Is there a planned release date for this fix?

[ar]

Q4/2020 is a reasonable bet, but you can use a pinned SNAPSHOT meanwhile.

[christopher-grech]

Is that something you need to do, the pinned SNAPSHOT?

[ar]

No, you just specify the full snapshot filename, including timestamp.
See http://jpos.org/maven/org/jpos/jpos/2.1.5-SNAPSHOT/

[christopher-grech]

Awesome, thanks!