From: Archie Cobbs (archie@whistle.com)
Date: Wed Dec 09 1998 - 21:00:07 EST
Tim Wilkinson writes:
> What do Sun say on this subject? After all they must have JNI code which
> calls 'malloc' - what to they say you should do?
>
> > Godmar Back writes:
> > > Could we come up with a set of rules as to when to include "config.h"
> > > and when not, and also a statement about the malloc redefinition issue?
> > > I think #define malloc if you include "jni.h" might just be plain wrong?
> > > It seems it's a big mess at this point.
> >
> > Why don't we just avoid using "malloc" everywhere in the source tree
> > (except the GC). Use "kmalloc" instead or something.
> >
> > I think redefining things that this is extremely misleading. Same
> > thing goes for "read", "write", etc.. Why not "kread", "kwrite" ??
I think Godmar's right about JNI -- it doesn't say anything specific
about what ANSI functions you can use.
My comment was more simple: it's confusing to redefine "well known"
identifiers like malloc, read, write, etc. to mean something different
from what people expect them to.
For example, I almost checked in a patch that would make the class
reading code use <stdio.h> routines to get the advantage of buffering,
by replacing read(), write(), etc with fread(), fwrite(), etc.
But the I had no idea this would screw up threading because read()
and write() are actually not the normal system calls you know and love.
Anyway, is anyone interested in a "rename" project? That is, everywhere
there's a use of the "fake" malloc, replace with kmalloc(), and change
the corresponding #define. I might take a shot at it at some point.
In the meantime, who has a complete list of these "fake" identifiers?
Thanks,
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:57:10 EDT