bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] GNUlib realloc POSIX comformance


From: Yoann Vandoorselaere
Subject: Re: [Bug-gnulib] GNUlib realloc POSIX comformance
Date: Wed, 17 Nov 2004 23:16:20 +0100

On Wed, 2004-11-17 at 22:48 +0100, Bruno Haible wrote:
> Yoann Vandoorselaere wrote:
> > - Quoting POSIX realloc definition:
> >   1. "If size is 0 and ptr is not a null pointer, the object pointed to
> >       is freed."
> > ...
> > First, the way GNUlib realloc() is implemented contradict with POSIX
> > definition #1.
> >
> > GNUlib realloc() will set size to 1 if the provided size is 0,
> > regardless of whether the provided pointer is NULL, which mean we will
> > allocate a 1 byte block instead of freeing the block when the pointer is
> > NULL as per #1 POSIX recommendation.
> 
> I don't see a POSIX violation here. POSIX says
>   "If size is 0 and ptr is not a null pointer, the object pointed to is freed.
>    ...
>    If size is 0, either a null pointer or a unique pointer that can be
>    successfully passed to free() shall be returned."
> 
> What gnulib/lib/realloc.c does, is to free() the argument ptr and then call
> malloc(1). Except that instead of doing this in two calls, it has optimized
> it into a single call:  realloc(ptr, 1). This is indistinguishable from
> the caller's point of view.

Well, I'm not sure I understand your argument: As I see it, GNUlib
realloc won't free the pointer ever if the provided size is zero. 

As I understand it, rpl_realloc will replace the regular realloc call,
in order to provide consistant behavior, but it itself depend on the
regular libc provided realloc() call. Or am I missing something ?

If the above is correct, then rpl_realloc() will not free the pointer
even if the provided size is zero.

> > Second, and IMHO GNUlib should not make a choise regarding the
> > 'implementation defined' part of the #2 POSIX definition (setting size
> > to 1 if the provided size is zero).
> 
> The point of lib/malloc.c and lib/realloc.c is precisely to have this
> behaviour the same across all platforms.
>
> If you don't want this, you are free to not use the 'malloc' and 'realloc'
> modules.
> 
> > I personnally would assume a call to
> > malloc/realloc with size being 0 to be a bug in my code.
> 
> OK, and how do you find this bug? 

Well, you're supposed to check the realloc() return value... And if the
function itself crash, then you have a good hint of what's going on.

IMO a function is not supposed to check for users programming error, but
that's a very discussable point of view. Some programmer like to check
for NULL pointer passed to function and return an error if that happen;
other programmer will let the program crash because of the NULL pointer
dereference and will expect the user to fix it's program.

Since POSIX say the result of this is implementation defined, GNUlib can
choose to support the approach it prefer, that's a simple question of
taste, and my problem is more with the other issue (realloc should
free() the pointer if size is zero, and the pointer is not NULL).

-- 
Yoann Vandoorselaere <address@hidden>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]