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... 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. > > /* 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? I think that it is sufficient to clearly document the requirement to define or not JBYTE_IS_NOT_SIGNED_CHAR appropriately. We both probably know very few platforms (I know of none, but I don't currently work on embedded processors...) that do not have 8-bit bytes (=> chars). This function is simply an appropriate test to add to a configure script in a GNU environment, for the programmer's convenience *only*. > > /* 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. > And a little stylistic nit: it isn't a good idea to cat return values > from malloc(). "cat"? What do you mean? [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. ;-)] Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath