On Wed, Sep 14, 2005 at 12:01:27AM +0200, Kurt Roeckx wrote: > On Tue, Sep 13, 2005 at 08:46:24PM +0200, Andreas Jochens wrote: > > On 05-Sep-13 19:52, Kurt Roeckx wrote: > > > Pretty please stop using longs as something that can hold a > > > pointer. In general you should not cast a pointer to any integer > > > type. If you really have to, use an intptr_t type. > > > > Believe me, a 'long' will do. There is no architecture where > > a 'long' can not hold a full pointer. The linux kernel as > > just one example heavily relies on the fact that > > sizeof(long)>=sizeof(pointer). > > You're assuming either an (I)LP32 or (I)LP64 architecture here. > An LLP64 architecture still has a long as 32 bit while a pointer > is 64 bit. The best example of an LLP64 architecture out there > is windows x64. > > That the kernel can assume that a long is enough to hold a > pointer is because that's how they defined a long to be. > > > Using 'intptr_t' will lead to problems because older C environments do > > not know about it and sometimes 'configure' scripts do ugly things with > > 'intptr_t'. As an example, 'e2fsprogs' broke with gcc-4.0 because it > > used 'intptr_t'. > > intptr_t exists for about 10 years now, in either inttypes.h > or stdint.h. And if something breaks you should fix it. It's > not that hard to make proper configure checks.
you exchange long and jlong here. For long your statements are correct. But for jlong which is specified by the Java language specification its not. jlong is always 64 bit, not matter what platform. The code that borked out was JNI C code which is bound to the types defined in jni.h which (nearly) each Java runtime environment includes. The types are clearly defined. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
