This is the mail archive of the
libc-alpha@cygnus.com
mailing list for the glibc project.
Re: [Andrew Pimlott <pimlott@abel.MATH.HARVARD.EDU>] realloc(p, 0) vs. free
- To: Wolfram Gloger <wmglo@dent.med.uni-muenchen.de>
- Subject: Re: [Andrew Pimlott <pimlott@abel.MATH.HARVARD.EDU>] realloc(p, 0) vs. free
- From: Roland McGrath <roland@frob.com>
- Date: Wed, 28 Apr 1999 18:46:35 -0400
- Cc: aj@arthur.rhein-neckar.de, libc-alpha@cygnus.com, pimlott@abel.MATH.HARVARD.EDU
> Well, as the comment in the source says, when malloc(0) returns a
> unique pointer (like it does currently in glibc) it seems consistent
> that realloc(...,0) does so too. So, if the standard really requires
> that realloc(...,0) frees then we should also consider changing
> malloc(0) to return NULL IMHO.
Consistency is not the paramount issue here, compatibility is. We must
free on realloc(...,0) because the standard says so. The standard allows
malloc(0) to return non-null (something you can free) because some existing
programs depend on that (note that the fact that free(0) is a no-op makes
fewer programs depend on it than might have done, but still some will).
We chose to make malloc(0) return non-null in glibc for the same reason:
because some existing program assumed it would.