This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] mtrace: properly handle realloc (p, 0)


On Wed, Jan 02, 2013 at 11:26:03PM +0100, Andreas Schwab wrote:
> KOSAKI Motohiro <kosaki.motohiro@gmail.com> writes:
> 
> >> KOSAKI Motohiro <kosaki.motohiro@gmail.com> writes:
> >>
> >>> realloc (p, 0) behavior is an implementation defined
> >>
> >> No.
> >
> > Interesting. So, I reread
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_400.htm. If we
> > don't agree it is implementation defined. realloc(p, 0) should behave
> > as BSD. then your patch is incorrect. no?
> 
> POSIX.1-2008 says: "If size is 0 and ptr is not a null pointer, the
> object pointed to is freed."  That's pretty conclusive.

It's not. Per ISO C, the original object is ALWAYS freed by realloc
unless it fails. The returned pointer is a pointer to a new object
with the same contents (up to the minimum of the old and new size).
POSIX has rewritten the specification of realloc in terms of changing
the size of an object, a concept that does not exist in plain C (for
very good reason).

Anyway, the requirement that realloc(ptr,0) free the object pointed to
by ptr does not preclude making a new allocation as if by malloc(0).
The POSIX language is just confusing because the only place they kept
the language from ISO C about freeing the object was in the case where
size is 0.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]