Re: experimenting with realloc behaviour

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.

Re: experimenting with realloc behaviour

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

Re: experimenting with realloc behaviour

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

Re: experimenting with realloc behaviour

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

Re: experimenting with realloc behaviour

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 —

Re: realloc: Improve documentation

Alejandro Colomar wrote: > > +(on musl libc, macOS, FreeBSD, NetBSD, OpenBSD, Solaris, Cygwin). > > Are you sure OpenBSD is on this list? Yes. 1. I checked it on OpenBSD 7.6, with the program that I attached. 2. It is consistent with the experiment that I had done in 2011: https://sourceware.org/

Re: realloc: Improve documentation

On Sat, Oct 19, 2024 at 02:23:44PM GMT, Paul Eggert wrote: > Thanks. Some further improvements: > > * Document whether realloc can fail when not growing a region. > > * Mention what happens to errno. > > * Mention how the ISO C standard has evolved here. > > * Give more details as to which glib

Re: realloc: Improve documentation

Paul Eggert wrote: > Thanks. Some further improvements: > > * Document whether realloc can fail when not growing a region. > > * Mention what happens to errno. > > * Mention how the ISO C standard has evolved here. > > * Give more details as to which glibc versions do what. > > * In the "pract

Re: realloc: Improve documentation

Alejandro Colomar wrote: > > >(C) usually succeeds and returns a unique zero-size object. > > >And there is also > > >(D) usually succeeds and returns a pointer to freshly-allocated > > > memory > > >of 1 byte. > > I'm not entirely sure what you mean by C and D. I

Re: realloc: Improve documentation

Thanks. Some further improvements: * Document whether realloc can fail when not growing a region. * Mention what happens to errno. * Mention how the ISO C standard has evolved here. * Give more details as to which glibc versions do what. * In the "practical" section, don't bother mentioning p

Re: [PATCH] Mention WG14 N3322 in manual

Paul Eggert wrote: > > Do you happen to know whether this proposal has already been approved? > > Yes, it was accepted by WG14 last week. See: > > https://sourceware.org/pipermail/libc-alpha/2024-October/160375.html Thanks. I've reported this glibc bug: https://sourceware.org/bugzilla/show_bug.c

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Paul, On Sat, Oct 19, 2024 at 11:24:08AM GMT, Paul Eggert wrote: > On 2024-10-19 09:14, Alejandro Colomar wrote: ... > > On Sat, Oct 19, 2024 at 10:25:52AM GMT, Bruno Haible wrote: ... > > > What I would therefore suggest — if we want to change Gnulib at all > > > regarding realloc — is

Re: [PATCH v1] realloc: Be consistent with malloc

On 2024-10-19 09:14, Alejandro Colomar wrote: ... On Sat, Oct 19, 2024 at 10:25:52AM GMT, Bruno Haible wrote: ... 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. That would be bad. Pr

Re: [PATCH v1] realloc: Be consistent with malloc

On 2024-10-19 01:25, Bruno Haible wrote: If not, can you please summarize the conclusions? I think Alejandro has done that now. it would be premature to change lib/realloc.c, _before_ glibc has made any change. Yes, we're working on the glibc side. (It's a little question of sche

Re: [PATCH v1] realloc: Be consistent with malloc

On 2024-10-19 05:26, Siddhesh Poyarekar wrote: Yeah, it's more likely this one: Thanks. I verified this by inspecting the diffs[1] from glibc 2.1 to 2.1.1. The suggestions I made in libc-alpha[2] for your draft tunables patch[3] should therefore be amended to say glibc version 2.1.1 (1999) n

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Bruno, On Sat, Oct 19, 2024 at 10:25:52AM GMT, Bruno Haible wrote: > Paul Eggert wrote: > > For gnulib readers: this new bug-gnulib thread is following up on this > > long libc-alpha thread: > > > > https://sourceware.org/pipermail/libc-alpha/2024-October/160645.html > > Thanks for the conte

Re: [PATCH v1] realloc: Be consistent with malloc

Hi Paul, On Fri, Oct 18, 2024 at 04:24:32PM GMT, Paul Eggert wrote: > [cutting the cc list down to bug-gnulib] > > Surely that's not enough; we'd need to replace realloc on current glibc > platforms, and not replace realloc on hypothetical future glibc platforms > that behave more compatibly with

Re: realloc: Improve documentation

Hi Bruno, On Sat, Oct 19, 2024 at 02:23:50PM GMT, Bruno Haible wrote: > I wrote: > >According to our doc, there are three possible behaviours of the realloc > >function: > >With a non-NULL pointer argument p, C17 says that it is > >implementation-defined whether realloc (p,

Re: [PATCH v1] realloc: Be consistent with malloc

On 2024-10-19 08:19, Bruno Haible wrote: Alejandro Colomar wrote in : - glibc, in 2006/2007, made a so-called bugfix change to conform to C89, which effectively made realloc(p,0) non-conforming to C99. This happened

realloc: Improve documentation

I wrote: >According to our doc, there are three possible behaviours of the realloc >function: >With a non-NULL pointer argument p, C17 says that it is >implementation-defined whether realloc (p, 0) frees p. Behavior varies > on >(A) whether realloc (p, 0) always fre

Re: [PATCH v1] realloc: Be consistent with malloc

Alejandro Colomar wrote in : > - glibc, in 2006/2007, made a so-called bugfix change to conform to >C89, which effectively made realloc(p,0) non-conforming to C99. This >happened in the following commit: > > comm

Re: [PATCH v1] realloc: Be consistent with malloc

Paul Eggert wrote: > For gnulib readers: this new bug-gnulib thread is following up on this > long libc-alpha thread: > > https://sourceware.org/pipermail/libc-alpha/2024-October/160645.html Thanks for the context, Paul. I haven't read the entire thread. Is the following summary (from a summari