Date: Wed, 25 Sep 2002 16:02:37 -0700 From: David Schultz <dschultz@uclink.Berkeley.EDU> To: Peter Jeremy <peter.jeremy@alcatel.com.au> Cc: stable@FreeBSD.ORG Subject: Re: [v]asprintf leaks memory Message-ID: <20020925230236.GA60375@HAL9000.homeunix.com> In-Reply-To: <20020925214322.GL495@gsmx07.alcatel.com.au> References: <20020925133219.GA59210@HAL9000.homeunix.com> <20020925214322.GL495@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Thus spake Peter Jeremy <peter.jeremy@alcatel.com.au>: > On 2002-Sep-25 06:32:19 -0700, David Schultz <dschultz@uclink.Berkeley.EDU> wrote: > >2) reallocf(NULL, x) is equivalent to malloc(x), which is the > > source of this bug. Maybe it shouldn't do that. [...] > IMHO, the ability to realloc(NULL, x) simplifies code: Where you have > a grow-on-demand buffer, there's no need to special-case the first > use. In wrapper functions (eg zrealloc()), there's no need to > explicitly check for NULL. Good point. I'm not familiar with the historical use of the function, but I assumed that once you destroy a buffer due to an allocation failure, you don't want to reallocate it with reallocf(). NULL *is* a special case in some sense because if your buffer got set to NULL in a previous call to reallocf(), you've lost the original contents, so there's little point in continuing to fiddle with it. I thought the whole point of the nonstandard semantics of reallocf() was that if something goes wrong, you basically want to give up on the buffer. If you really mean ``give me a *new* buffer,'' then you usually call malloc() explicitly. 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. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020925230236.GA60375>