>From: Kevin Sullivan <ksulliva@psc.edu>
>
>On Mon, 26 May 1997 13:29:25 EDT, maximum entropy says
>>For what it's worth, Bash-2.00 has similar problems and configuring to
>>build without GNU malloc seems to work as a workaround.
>
>I tracked this down somewhat in bash-1.14.7.  Bach (actually readline)
>calls tgetent().  tgetent calls cgetent() with a NULL variable several
>times.  The man page doesn't document it, but reading the source shows
>that a NULL variable makes cgetent malloc() a buffer.  Once tgetent is
>done, it free()s the buffer.  See /usr/src/lib/libterm/termcap.c line
>148.
>
>The problem seems to be that cgetent uses calloc() to get the memory.
>Bash defines a replacement malloc and free, but not a calloc.  Thus
>the memory is allocated with NetBSD's malloc and freed with bash's
>free.  Crash.
>
>I haven't sent a pr since I'm not sure where the bug lies.  It seems
>stupid to define your oven malloc but not calloc; but it seems odd
>that our calloc doesn't just call malloc (done for performance
>reasons, maybe?).  I'm also not sure if this bug affects non-pmax
>systems.

bash-2.00 with gnu malloc seems to work without trouble on
NetBSD-i386.  But from your description of the problem, I would tend
to think that this is just luck -- I think that relying on some
particular system implementation of calloc() while using your own
malloc() and free() is a bad idea in a portable application.

entropy

--
entropy -- it's not just a good idea, it's the second law.