Re: jni-h-fix-warning-1.patch

[Steven Augart]

Tom Tromey wrote:
> > > > > > "Steven" == Steven Augart <address@hidden> writes:
>
> Steven> * include/jni.h.in: Fix a warning you otherwise get when compiling
> Steven> with gcc (not g++) with the -Wstrict-prototypes flag.
>
> _Jv_func is used only as a placeholder for reserved functions in
> various structs.  Sun uses "void *" here, but I think that is
> pedantically incorrect, since there is no guarantee that a void* and a
> function pointer have the same size.  

Whoops.  My bad.  Not that it would have affected anything, since any 
VM that actually uses that structure as the target of an assignment 
should just assign 0 or NULL to the vacant members.  But:

1) Please disregard the patch.

2) In reviewing all of include/jni.h, (and running grep-find across 
Classpath), I see that we are also using _Jv_func in the struct 
JNIInvokeInterface.  Those are the two places we're concerned with 
filling in holes with a _Jv_func.

3) The JNI Spec seems to leave the types (and names) of the empty 
members of the structure unspecified.  It's a good question what would 
be proper.  Of course, for every machine for which JavaSoft ships an 
implementation, all pointers are a machine word long, so the issue is 
moot.

Your function pointer issue is certainly pedantically correct. I've 
actually programmed in assembly on the PDP-10, where char pointers are 
indeed larger than other kinds of pointers.  (This was before ANSI C 
'89; the same would apply to void * today).

However, in the downloadable 1.4.2 docs, I find this structure defined 
 as what RegisterNatives handles:

typedef struct {
    char *name;
    char *signature;
    void *fnPtr;
} JNINativeMethod;

So we might as well use "void *".

(In immediate self-contradiction, RegisterNatives then goes on to say:

  The function pointers nominally must have the following signature:

  ReturnType (*fnPtr)(JNIEnv *env, jobject objectOrClass, ...);

)

> Of course that brings up the
> problem: perhaps we're being incompatible (with a buggy
> implementation), and we should just use `void *' ourselves.

I would recommend this.  I would also recommend using void * for both 
C and C++, just as Sun does.
> Another option would be to unconditionally use `(void)' for both C
> and C++.  That would be a little cleaner, one less ifdef.

By (void), I assume you mean "void (*)(void)" ?  A simple "void *" 
shares its virtue of not requiring an #ifdef.

--
Steven Augart

Jikes RVM, a free, open source, Virtual Machine:
http://oss.software.ibm.com/jikesrvm