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. _______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
