Re: [Bug-gnulib] GNUlib realloc POSIX comformance

[Bruno Haible]

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.

> 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? If you run valgrind, it will tell you
about such things. But if you don't? Then your program will run fine on
glibc systems and do wrong things or crash on other platforms.

It's your choice.

For GNU gettext, I've chosen to avoid all calls to malloc(0) and realloc(p,0),
and I rely on valgrind for verifying that.

Bruno