Re: [cp-patches] RFC: replacing jni_md-x86-linux.h by a generic jni_md.h

[Tom Tromey]

>>>>> "Dalibor" == Dalibor Topic <address@hidden> writes:

Dalibor> Kaffe indeed installs config-int.h along with jni_md.h. I
Dalibor> think the file should be renamed then to something like
Dalibor> classpath_stdint_wrapper.h to make sure it differentiates
Dalibor> itself from other headers.

Yeah, this would be good.

>> And, simply installing it may be
>> wrong as it could redefine things like int8_t or whatever.

Dalibor> If the macro works as it should (delegating to
Dalibor> stdint.h/inttypes.h when those are available), I don't think
Dalibor> that is going to be an issue. Could you elaborate?

Sun doesn't exactly define what their header files do very well, but
the potential issue is that on some platform we could define, say,
int8_t in a way that conflicts with however the application itself
defines it.

I'm inclined to just ignore this problem unless/until it bites us.

Dalibor> I am not quite sure what the best approach is here. Would #including
Dalibor> "jni_md_vm.h", which would be empty per default, and having all JNI*
Dalibor> macros be defined conditionally upon them being #if ! defined be a
Dalibor> workeable solution, as it would give those runtimes that need to
Dalibor> redefine JNI* an entry point?

At least JNIIMPORT and JNIEXPORT have to be defined on Windows.
In libgcj's jni_md.h we just check some platform defines.

Tom