From owner-freebsd-stable Wed Sep 25 16: 2:48 2002 Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4B8937B401 for ; Wed, 25 Sep 2002 16:02:46 -0700 (PDT) Received: from HAL9000.homeunix.com (12-232-220-15.client.attbi.com [12.232.220.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01EED43E6E for ; Wed, 25 Sep 2002 16:02:46 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: from HAL9000.homeunix.com (localhost [127.0.0.1]) by HAL9000.homeunix.com (8.12.6/8.12.5) with ESMTP id g8PN2b8E060437; Wed, 25 Sep 2002 16:02:37 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Received: (from das@localhost) by HAL9000.homeunix.com (8.12.6/8.12.5/Submit) id g8PN2bNe060436; Wed, 25 Sep 2002 16:02:37 -0700 (PDT) (envelope-from dschultz@uclink.Berkeley.EDU) Date: Wed, 25 Sep 2002 16:02:37 -0700 From: David Schultz To: Peter Jeremy Cc: stable@FreeBSD.ORG Subject: Re: [v]asprintf leaks memory Message-ID: <20020925230236.GA60375@HAL9000.homeunix.com> Mail-Followup-To: Peter Jeremy , stable@FreeBSD.ORG References: <20020925133219.GA59210@HAL9000.homeunix.com> <20020925214322.GL495@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020925214322.GL495@gsmx07.alcatel.com.au> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thus spake Peter Jeremy : > On 2002-Sep-25 06:32:19 -0700, David Schultz 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