Re: [cp-patches] Patch JCL_realloc()] (late, because accidently sent to wrong address)

[Dr. Torsten Rupp]

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,