develooper Front page | perl.perl5.porters | Postings from June 2003

Re: your malloc patches

Thread Previous | Thread Next
Ilya Zakharevich
June 15, 2003 10:00
Re: your malloc patches
Message ID:
On Sun, Jun 15, 2003 at 12:53:47PM +0300, Jarkko Hietaniemi wrote:
> Thanks, looking much better, but I'm afraid a bit more work is needed.
> Too many GCCisms, a strange include file, and an assertion failure.
> (1) The ,) macro was still there: in perl.h:
> #define MALLOC_CHECK_TAINT2(argc,argv)  MALLOC_CHECK_TAINT(argc,argv,)
> This just isn't cricket for non-GCC compilers (Solaris, AIX, and Tru64
> claim a syntax error, IRIX seems to tolerate it).  That a function
> call (Perl_doing_taint in this case) gets expanded to func(a,b,) just
> isn't going to work.  (What does leaving out an argument like that
> _mean_, anyway?  An implicit 0?)

It is a *macro*, not a function call!  Macros operate on strings.  An
empty string is a perfectly valid string (though I do not know what
the C standard says on this).

Anyway, this slot is not used, so put there NOTUSED.

> (2) Solaris Workshop cc doesn't like the malloc code:
> "malloc.c", line 1209: a cast does not yield an lvalue
> "malloc.c", line 1221: a cast does not yield an lvalue
> "malloc.c", line 1241: a cast does not yield an lvalue
> "malloc.c", line 1520: cannot recover from previous errors
> cc: acomp failed for malloc.c

Thanks for a careful approach.  I won't be able to examine this for
several days (at least); my 11h flight leaves in a few hours.

> (3) What is the io.h used in malloc.?
> ...
> #    include <memory.h>
> #    include <io.h>
> #    include <string.h>
> ...

OK, this is probably OS/2-EMXism.  There should be a place where
write() lives, though...

> (4) Tru64 compiles but then miniperl fails an assertion (a 64-bit problem?):

This is a bug.  Most probably not in malloc(), but in the caller code.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About