I wrote:
> 3) When behaviour changes are needed in Gnulib APIs, what we usually do is
>    a transition period, in which the developer is helped through appropriate
>    warnings or error messages.
> 
>    What I would therefore suggest — if we want to change Gnulib at all
>    regarding realloc — is to make
>      realloc (ptr, 0) with ptr != NULL
>    abort.
> 
>    This is allowed by ISO C 23.
> 
>    We can do this for a transition period of 3 years. And then, in 3 years,
>    look what behaviour (A, B, C, or D) would be useful to have, considering
>    what glibc has done until then.
> 
>    The developer would get a clear error message, with a gdb stack trace,
>    when this occurs.

Thinking more about it: The proper place for such abort()s in case of undefined
behaviour are the undefined-behaviour sanitizers of gcc and clang.

I therefore reported this in the gcc and clang bug trackers:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117233
https://github.com/llvm/llvm-project/issues/113065

When these get implemented, what a package maintainer can do is:
  1. Invoke gnulib-tool with options --avoid=realloc-posix --avoid=realloc-gnu
  2. Build the package with CC="gcc -fsanitize=undefined" or
     CC="clang -fsanitize=undefined"
  3. Run the package's test suite.

But I understand that you want to conduct experiments now, without waiting
several months for a new gcc or clang version.

Alejandro Colomar wrote:
> > So, it would be premature to change lib/realloc.c, _before_ glibc has
> > made any change.
>
> Paul suggested that gnulib could be used to test the waters for glibc.

What I would propose is that the modules 'realloc-posix' and 'realloc-gnu'
implement a configure option

  --enable-sanitized-realloc    change realloc so that it aborts in cases
                                of undefined behaviour (experimental)

and that by default, i.e. when this option is not enabled, there is *no change*
compared to today.

With this option, a package maintainer can:
  1. Invoke gnulib-tool with the same options as usual (the module realloc-posix
     will almost certainly be among the dependencies).
  2. Build the package as usual.
  3. Run the package's test suite.

Then, if there is need, you can implement other behaviours of realloc,
equally guarded by an --enable-something option.

What is important to me is:
  - Gnulib's default behaviour does not change until glibc is changed.
    I.e. the options are opt-in.
  - The options are marked experimental, so that we can remove them when
    the experimental phase is over.

Bruno




Reply via email to