Front page | perl.perl5.porters |
Postings from June 2003
Re: your malloc patches
Thread Previous
|
Thread Next
From:
Ilya Zakharevich
Date:
June 15, 2003 10:00
Subject:
Re: your malloc patches
Message ID:
20030615165958.GA28793@math.berkeley.edu
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.
Thanks,
Ilya
Thread Previous
|
Thread Next