Date: Thu, 26 Sep 2002 07:43:22 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: David Schultz <dschultz@uclink.Berkeley.EDU> Cc: stable@FreeBSD.ORG Subject: Re: [v]asprintf leaks memory Message-ID: <20020925214322.GL495@gsmx07.alcatel.com.au> In-Reply-To: <20020925133219.GA59210@HAL9000.homeunix.com> References: <20020925133219.GA59210@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. The man page specifically states that realloc(NULL, x) is equivalent to malloc(x) and that reallocf() is the same as malloc() except that it frees the argument if the realloc() fails. 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. Also IMHO, having realloc() and reallocf() behave differently for NULL buffers would cause much confusion. At the very least, it would make converting realloc() to reallocf() significantly more difficult. If reallocf(NULL, x) isn't equivalent to malloc(x), what behaviour should it have? In the case of [v]asprintf(3), propagating the NULL simplifies the code because it propagates a preceeding error state. Other uses for reallocf() may prefer different behaviour. Overall (IMHO): - realloc(NULL, x) == malloc(x) is the cleanest behaviour - reallocf(NULL, x) similar to realloc(NULL, x) meets POLA - Applications that need different semantics should implement them themselves. Peter 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?20020925214322.GL495>