Dear Mark,
* native/jni/classpath/jcl.h, native/jni/classpath/jcl.c, native/jni/java-io/java_io_VMFile.c: Inserted native layer macros for OS functions, added parameter for old memory size to JCL_realloc() to be able to make an malloc() on system where no realloc() is available.
I don't really get this patch. There is a lot of changes, reformatting, in this patch that make it difficult to see what is really going on. The patch also uses TARGET_NATIVE_MEMORY_ALLOC and TARGET_NATIVE_MEMORY_REALLOC macros which we never define
Oh...sorry again. I accidently ignored to add native/target/generic/target_generic_memory.h and native/target/Linux/target_native_memory.h where these macros are included. Unfortunatelly it is very difficult for me to make simple patches with only a single set of changes (like requested by Michael), because usually I make the system running here including all needed changes. Then I have to do "backsteps" to make several single patches for some general change (e. g. replacement of OS functions). This took a lot of time and obviously this could also fail. I would like to supply patches with all needed changes included to avoid missing parts, but this seems to be to complex on the other side?
(and I thought we agreed to get rid of these kind of macros and would use normal functions as much as possible in the future.)
When I remember right, the agreement was not to remove the macros completely, but instead make them into "alias"-names for target specific implementations of some OS-function. I prepared a POSIX layer which should replace the "generic" layer with this approach. Each macro simply call a target specific native function resp. the POSIX compliant function (the POSIX layer use autoconf results). For us the native macors are very important, because we do not have a complete autoconf for all systems. Most of our systems are embedded systems with cross-compilers and there are many difficulties when using autoconf, e. g. functions which are available, but can not be used, broken system headers, different compiler options (autoconf is based on gcc-compatible compiler). If the macros would be discarded in Classpath, I see no way for us to go on with native code in Classpath.
We should probably use autoconf to properly support systems that don't have a working realloc implementation. Autoconf has the following support for it:
Macro: AC_FUNC_REALLOC If the realloc function is compatible with the GNU C library realloc (i.e., `realloc (0, 0)' returns a valid pointer), define HAVE_REALLOC to 1. Otherwise define HAVE_REALLOC to 0, ask for an AC_LIBOBJ replacement for `realloc', and define realloc to rpl_realloc so that the native realloc is not used in the main project. See AC_FUNC_MALLOC for details.
For a cross-compiler system a test usually can not be executed, only compilation is possible. But for this specific case of realloc(), this is not sufficient, because the functions exists, but does not work. I see no way with autoconf to solve this problem (ideas are welcome). Thus that is the reason, why it is so important for me to be able to replace some specific target OS function by another implementation (e. g. malloc() and free()). Of course it would be possible to use some #ifdef-construct to handle this case, but imho this would make the code more complex (for each OS function a target-specific alternative function have to be integrated in a big #ifdef-#elsif-#else statement) and some manual setting of autoconf-values is needed (how to do this?). One other example: I yust reviewed
classpath/native/jni/java-util/java_util_VMTimeZone.c
where the time-zone id is detected (Java_java_util_VMTimeZone_getSystemTimeZoneId). This function is not portable to some of our systems (e. g. time(), mktime(), localtime() can not be used, even they are available, because the returned values are wrong). Also the function is already very complex, because there are 5 different autconf-values used. Of course the function may run on many Unix-like systems, but because only half of our systems are Unix-like, the function is useless on the others.
My proposal - as discussed some time ago in the mailing list - is to keep the structure of the target native layer with the macros, but change the content into function calls which use autoconf whenever possible. This would keep the code flexible enough for strange systems (e. g. someone can replace functions for a specific target), too, but also readable and debuggable.
Best regards,
Torsten
PS: I will send a new patch soon as possible,
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
