>>>>> "Dalibor" == Dalibor Topic <[EMAIL PROTECTED]> 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 _______________________________________________ Classpath-patches mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath-patches
