Struct.NumberField.getString() downcasts to int

[ahilananantha]

If somebody does a String.valueOf(myStruct.foo)... where foo is a u_int64_t field... instead of String.valueOf(myStruct.foo.get()) which will be simple and safe, it looks to me like the code is doing an unintentional downcast to int.

I'm seeing the issue in Struct.NumberField:

    /**
     * Returns a string representation of this <code>Address</code>.
     *
     * @return a string representation of this <code>Address</code>.
     */
    @Override
    public java.lang.String toString() {
        return java.lang.Integer.toString(intValue(), 10);
    }

the intValue() call will be to Struct.IntegerAlias.intValue():

    @Override
    public int intValue() {
        return (int) get();
    }

which does the downcast. Perhaps call longValue() instead?

[headius]

It does appear that this logic does not support 64-bit values at all. Changing the toString is only one small part of it; note that NumberField.longValue also calls intValue and upcasts it to a long. It's unclear to me if we can just switch all of these classes to actually treat the contained value as a long.

Thoughts?

[ahilananantha]

AFAICT, NumberField.longValue is always overridden in the places that matter, e.g. IntegerAlias, Signed64, Unsigned64, SignedLong, UnsignedLong. Perhaps you could make all those methods abstract to avoid confusion?

[ahilananantha]

And calling longValue() will still be wrong if the number is a float. Looks like it's more correct to make the method abstract.

[ahilananantha]

The shortest fix seems to be to copy over the toString() method of Signed64 / Unsigned64 / SignedLong / UnsignedLong into IntegerAlias and Unsigned32. The delicate series of overrides of longValue() and toString() in derived classes seems to handle every other case.

Alternately we can make longValue() and toString() abstract so that the code is easier to read but lengthier.