Subject: Re: pmax and tcsh
To: None <email@example.com>
From: maximum entropy <firstname.lastname@example.org>
Date: 05/27/1997 15:13:21
>From: Kevin Sullivan <email@example.com>
>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
>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
>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
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 -- it's not just a good idea, it's the second law.