On Wed, Sep 25, 2002 at 07:14:41PM -0400, Barney Wolff wrote:

> On Wed, Sep 25, 2002 at 04:02:37PM -0700, David Schultz wrote:
> > 
> > I don't really care one way or the other, but regardless of what
> > the manpage says, reallocf()'s semantics should probably match the
> > way it's already used.  Maybe what I found was an isolated bug and
> > reallocf() DTRT already.  In that case, the patch I posted should
> > probably be applied.
> 
> Could you please explain exactly how the original code leaks memory?
> Maybe I'm being dense today but I just don't see it.  If reallocf
> returns NULL the original buffer has been freed.

The asprintf() function works by allocating a relatively small (128 byte)
buffer for the data, then it calls __svfprintf() which calls __sfvwrite()
to write the data to the "file" (which is really a string). If __sfvwrite()
can't get enough memory for a bigger buffer, it sets fp->_bf._base to NULL
but does not change fp->_bf._size. When control returns to asprintf(),
it realloc()'s _bf._base to be _bf._size + 1 byte long. Because _bf._base
is already NULL, the call which was designed to shrink the buffer actually
allocates a new one (!) and returns the freshly allocated storage back
to the caller (!).

I'll apply David's patch...


Tim

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message

Reply via email to