Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unsigned types are not generated correct #23

Open
anxtfux opened this issue Feb 28, 2015 · 4 comments
Open

Unsigned types are not generated correct #23

anxtfux opened this issue Feb 28, 2015 · 4 comments

Comments

@anxtfux
Copy link
Contributor

anxtfux commented Feb 28, 2015

Since Java does not have unsigned primitive types the generated type for UInt8, UInt16, UInt32 must be short, int, long instead of byte, short, int. For UInt64 is no real solution available but here is the impact not as big as for the smaller types.

// Current UInt8
     public final byte getM0() {
        return _getByteField(0);
      }
      public final void setM0(byte value) {
        _setByteField(0, value);
      }
// Expected UInt8
     public final short getM0() {
        return _getByteField(0) & 0xFF;
      }
      public final void setM0(short value) {
        _setByteField(0, (byte) value);
      }
// Current UInt16
      public final short getM1() {
        return _getShortField(1);
      }
      public final void setM1(short value) {
        _setShortField(1, value);
      }
// Expected UInt16
      public final int getM1() {
        return _getShortField(1) & 0xFFFF;
      }
      public final void setM1(int value) {
        _setShortField(1, (short) value);
      }
// Current UInt32
      public final int getM2() {
        return _getIntField(2);
      }
      public final void setM2(int value) {
        _setIntField(2, value);
      }
// Expected UInt32
      public final long getM2() {
        return _getIntField(2) & 0xFFFF_FFFFL;
      }
      public final void setM2(long value) {
        _setIntField(2, (int) value);
      }
@dwrensha
Copy link
Member

Hm. I feel like representing an unsigned 32-bit integer as an int is a much more faithful representation than shoving it into a 64-bit long, and I don't like the idea of silently truncating bits in the setter methods. I don't think it's too much of a burden to ask that you do the conversions yourself if needed, especially now that Java 8 has methods like Integer.toUnsignedLong(int x) and Integer.compareUnsigned(int x, int y).

Maybe we just need better documentation for the current behavior?

@anxtfux
Copy link
Contributor Author

anxtfux commented Feb 28, 2015

With the current implementation the unsigned types have no meaning in Java. It's a nasty pitfall if you get negative values where it should be impossible only by missing to do the conversion yourself. I think it is very common to express unsigned values with the next higher type, especially for UInt8 and UInt16.

@digitwolf
Copy link

Hey guys, is there any update on this?
What is the right way of using uint16 in java? How to use short?

idlsoft pushed a commit to idlsoft/capnproto-java that referenced this issue Apr 6, 2022
@richardstephens
Copy link

We make use of the library jOOU to make working with unsigned integers easier, but it would be cool if we could have a codegen option for capnproto-java to generate these for us.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants