Paul Eggert wrote:
> > Well, if we go for some VARIABLE=VALUE option that is not visible through
> > './configure --help', it could be the name of some cache variable:
> >gl_cv_realloc_sanitize=yes
> >
> > Would that be OK?
>
> Yes, I think so.
Implemented through these two patches.
The fir
On 2024-10-19 18:23, Bruno Haible wrote:
Well, if we go for some VARIABLE=VALUE option that is not visible through
'./configure --help', it could be the name of some cache variable:
gl_cv_realloc_sanitize=yes
Would that be OK?
Yes, I think so.
Paul Eggert wrote:
> >--enable-sanitized-reallocchange realloc so that it aborts in cases
> > of undefined behaviour (experimental)
>
> Although something along these lines would work, the GNU Coding
> Standards say that --enable-* is for user-level facili
On 2024-10-19 15:06, Bruno Haible wrote:
What I would propose is that the modules 'realloc-posix' and 'realloc-gnu'
implement a configure option
--enable-sanitized-reallocchange realloc so that it aborts in cases
of undefined behaviour (experimental)
Alt
I wrote:
> 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.
Correction:
With this optio
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 —
