Re: Classpath build process and VM-specific issues

[Andrew Haley]

Etienne Gagnon writes:
 > On Wed, Apr 07, 2004 at 11:19:47AM +0100, Andrew Haley wrote:
 > >  > "jbyte" must have a single platform-specific definition, as all
 > >  > JVMs on that platform should be able to execute the same JNI
 > >  > library code (no recompilation required).
 > > 
 > > I didn't know that.  Is that requirement documented anywhere?  I can't
 > > see how you'd do it on a machine with 32-bit and 64-bit modes, for
 > > example.  Do we know that every JVM will use the same calling
 > > convention for CNI?
 > 
 > CNI is a gcj-specific thing, so gcj can do whatever they like...

Uh, thinko.  I mean JNI.

 > As for JNI, yes it is a requirement.  JNI was *specifically*
 > developed to get rid of the multiple VM-specific native interfaces
 > that were developed in early Java implementations (Sun's, Netscape's,
 > Microsoft's).
 > 
 > In the JNI specification (e.g. chapters 11 to 13 of ISBN 0-201-32577-2
 > "The Java Native Interface, Programmer's Guide and Specification), you
 > find the following text:
 > 
 >   11.1 Design Goals
 > 
 >   The most important goal of the JNI design is ensuring that it offers
 >   binary compatibility among different Java virtual machine
 >   implementations on a given host environment. The same native library
 >   binary will run on different virtual machine implementations on a
 >   given host environment without the need for recompilation.

That looks good, where it's possible.

 > >  > /* test function (unused).  This function will cause a compiler
 > >  >  * warning when jbyte != signed char */
 > > 
 > > Maybe, maybe not.  Is this guaranteed by the standard to cause a
 > > warning?
 > 
 > Do we really care?

No, not particularly.  I just wondered why you say this.

 > >  >   /* make a robust integer out of pointer value */
 > >  >   ptrdiff_t value = (char *) ptr - (char *) 0;
 > > 
 > > Don't do this subtraction, it isn't portable.  Use intptr_t instead.
 > 
 > ANSI/ISO 9899-1990 (the old standard, I guess) does not have intptr_t.

Okay, but ANS specifically does not allow you to do this subtraction.
Also, there is no guarantee that every pointer is representable as a
ptrdiff_t.  (6.5.6 Para 9, if you're interested)

 > > And a little stylistic nit: it isn't a good idea to cat return values
 > > from malloc().
 > 
 > 
 > "cat"?  What do you mean?

It's a special kind of typo that isn't detected by a spell checker.
:-)

It isn't a good idea to cast return values from malloc().  This is
because it can disguise a failure to #include <stdlib.h>.

 > [I know the example JNI code should have checked that malloc() had
 > actually succeeded.  And the code has a memory leak, as the
 > malloc()ed memory isn't freed, but this code was simply meant as a
 > test for wrapping/unwrapping native pointer...  Writing robust and
 > portable C code is painful. ;-)]

It certainly is!

Andrew.