Re: glibc realloc(ptr, 0) vs. C17 specification

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 06/08/2019 18:27, Eric Blake wrote:

> My personal take is that the Austin Group should permit existing glibc
> behavior insofar as glibc behavior doesn't violate C17.  Placing a
> restriction beyond C that would require a versioned realloc in glibc is
> not a good idea unless glibc developers first agree to be willing to go
> that route - so arguments describing pros and cons of glibc even
> considering a versioned realloc are helpful.   Florian has already given
> one argument against a versioned realloc based on the frequency of
> malloc interposition - given that there are already a number of
> libraries that replace malloc with their own implementation (whether for
> performance reasons such as jemalloc, tcmalloc; or for debug reasons
> such as valgrind), because having to replace two different versions of
> realloc across multiple implementations just makes life even more
> complicated.  But it's a tough call when I can't decipher whether C17 is
> self-consistent, and therefore can't state whether glibc is compliant as-is.
> 

Another issue with versioning realloc based on C standard versioning is it
might make libraries incompatible if they are build with different C standards,
another permutation developers will need to take care. Also static linking will
require some more hacking to export malloc with different name depending of the
__STDC_VERSION__. I don't think symbol versioning is the answer for this
possible issue.

Attachment: signature.asc
Description: OpenPGP digital signature