5 ms·

jlong is always 64 bits. I would be interested in knowing more details about platforms where your pointers are wider than 64 bits. Not impossible, but certainl

jlong is always 64 bits. I would be interested in knowing more details about platforms where your pointers are wider than 64 bits. Not impossible, but certainly pathological.

saagarjha 7y ago
Yeah, but a void pointer isn't always 64 bits…
- klodolph 7y ago
  I’m interested in the specific cases where it isn’t (where it’s larger than 64-bits). I can’t think of an example where a simple object pointer is larger than 64 bits. Can you run the JNI on those platforms?
JoeAltmaier 7y ago
Complex pointers (object/method pointers) can sometimes exceed that? Anyway, I see the issue, you're stuck having to do something and that's a pretty good solution. Maybe add an assert somewhere to the effect that sizeof(jlong) >= sizeof(pointer) which is free on your platform.
- klodolph 7y ago
  Sure, but if you go down chasing portability guarantees in e.g. the C++ spec, you’re going to go insane pretty quickly.
  - kllrnohj 7y ago
    That but also Java doesn't really give you a better option here. There's no IntPtr type in Java like there is in C#.
    - klodolph 7y ago
      The only point of IntPtr is to save four bytes on 32-bit platforms. Why look for a better option when jlong is damn well good enough?
- kllrnohj 7y ago
  > Complex pointers (object/method pointers) can sometimes exceed that? They can't. void* / intptr_t is a fixed-size, and at least on all platforms I run on that size is always 32-bit or 64-bit. Both of which fit perfectly fine in the always-64-bit jlong. If you're thinking of std::mem_fn or similar note that they are defined to return an undefined object not a pointer. So of course those can be larger than the size of a pointer, since they aren't a pointer. But sure toss in a static_assert(sizeof(jlong) >= sizeof(void*)) if you want.
  - JoeAltmaier 7y ago
    I guess I was thinking of virtual function pointer. Its larger than a regular function pointer, which is not necessarily the same size as a data pointer. But if you're dealing with object pointers only, all good!

jlong is always 64 bits. I would be interested in knowing more details about platforms where your pointers are wider than 64 bits. Not impossible, but certainly pathological.

saagarjha 7y ago

Yeah, but a void pointer isn't always 64 bits…

klodolph 7y ago
I’m interested in the specific cases where it isn’t (where it’s larger than 64-bits). I can’t think of an example where a simple object pointer is larger than 64 bits. Can you run the JNI on those platforms?

JoeAltmaier 7y ago

Complex pointers (object/method pointers) can sometimes exceed that? Anyway, I see the issue, you're stuck having to do something and that's a pretty good solution. Maybe add an assert somewhere to the effect that sizeof(jlong) >= sizeof(pointer) which is free on your platform.

klodolph 7y ago
Sure, but if you go down chasing portability guarantees in e.g. the C++ spec, you’re going to go insane pretty quickly.
- kllrnohj 7y ago
  That but also Java doesn't really give you a better option here. There's no IntPtr type in Java like there is in C#.
  - klodolph 7y ago
    The only point of IntPtr is to save four bytes on 32-bit platforms. Why look for a better option when jlong is damn well good enough?
kllrnohj 7y ago
> Complex pointers (object/method pointers) can sometimes exceed that? They can't. void* / intptr_t is a fixed-size, and at least on all platforms I run on that size is always 32-bit or 64-bit. Both of which fit perfectly fine in the always-64-bit jlong. If you're thinking of std::mem_fn or similar note that they are defined to return an undefined object not a pointer. So of course those can be larger than the size of a pointer, since they aren't a pointer. But sure toss in a static_assert(sizeof(jlong) >= sizeof(void*)) if you want.
- JoeAltmaier 7y ago
  I guess I was thinking of virtual function pointer. Its larger than a regular function pointer, which is not necessarily the same size as a data pointer. But if you're dealing with object pointers only, all good!