Thus spake Peter Jeremy <[EMAIL PROTECTED]>: > On 2002-Sep-25 06:32:19 -0700, David Schultz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
