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

Re: your malloc patches

Thread Previous | Thread Next
Jarkko Hietaniemi
June 20, 2003 03:01
Re: your malloc patches
Message ID:
> So if you disable bug-detection feature, things work.  ;-) So add

Of course I find your belief in the buglessness of your own code
admirable :-) but are you absolutely certain your new code works in
sizeof(int)==4,sizeof(long)==8,sizeof(ptr)==MEM_ALIGNBYTES==8 world?
(That's what Tru64 is.)

> -DNO_FILL_CHECK as a temporary measure.  Actually, apply the patch
> below, and -DFILL_CHECK_DEFAULT=0 (so that this may be changed at
> runtime).


> Anyway, I was wrong that I can't do better with detection of
> write-to-free()ed-or-not-yet-malloc()ed region (this is what happens
> above).  But before I do this (some work required), could somebody
> check what is the contents of memory when FILLCHECK_DEADBEEF() fails?

I'll find out.

> Thanks,
> Ilya
> P.S.  I find the message written by malloc.c:botch() misleading.  It is done by
>   #define	ASSERT(p,diag)   if (!(p)) botch(diag,STRINGIFY(p));  else
> and STRINGIFY() expands p - and with the current state of things the
> expansion may take hundreds of bytes; I do not remember cpp magic well
> enough: is it possible to do STRINGIFY_UNEXPANDED() in cpp?

I don't think so (if I understood your question).

Incidentally, I added the printing of __FILE__ and __LINE__ to the
botch().  You can grab the current state (as of change #19834) of
malloc.c from

Jarkko Hietaniemi <> "There is this special
biologist word we use for 'stable'.  It is 'dead'." -- Jack Cohen

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