From: Alejandro Colomar <alx@kernel.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Collin Funk <collin.funk1@gmail.com>,
"G. Branden Robinson" <g.branden.robinson@gmail.com>,
Paul Eggert <eggert@cs.ucla.edu>,
linux-man@vger.kernel.org, bug-gnulib@gnu.org,
libc-alpha@sourceware.org
Subject: When and why realloc(,0) was broken in glibc in 1999
Date: Mon, 3 Aug 2026 15:51:29 +0200 [thread overview]
Message-ID: <anCXCl5QbkDjsGzl@devuan> (raw)
In-Reply-To: <alpine.DEB.2.21.2608022219530.55540@angie.orcam.me.uk>
[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]
Hi Maciej,
> Date: 2026-08-02 22:23:36+0100
> From: "Maciej W. Rozycki" <macro@orcam.me.uk>
>
> On Sun, 2 Aug 2026, Alejandro Colomar wrote:
>
> > The original implementation in glibc would have been con‐
> > forming to C99. However, and ironically, trying to comply
> > with C99 before the standard was released, glibc changed
> > its behavior in glibc 2.1.1 into something that ended up
> > not conforming to the final C99 specification (but this is
> > debated, as the wording of the standard seems self‐contra‐
> > dicting).
>
> Well, this was a period when glibc was driven by personal preferences of
> one particular maintainer, so I don't think it is a good example in this
> discussion.
Just to clarify something about this, to which I didn't reply before:
we can't blame Drepper for this bug.
In this case, there was a discussion in the mailing list, and there was
no discrepancy against this change.
<https://sourceware.org/pipermail/libc-alpha/1999-April/000956.html>
It's just a case of a discussion that happened with incomplete
information, and which favoured standards conformance over common sense.
In fact, I was surprised when I learnt about this case, because I would
have expected Drepper to ignore the standard for being bogus.
Jonathan Larmour correctly noted in that discussion that glibc was not
conforming to C89.
<https://sourceware.org/pipermail/libc-alpha/1999-April/002394.html>
This finding from Jonathan should have triggered some more research, but
they didn't.
Roland McGrath pointed out his understanding of the (ambiguous) C89
specification, and claimed that it was a bug in glibc (and thus he seems
to have been in favour of the "fix" too).
<https://sourceware.org/pipermail/libc-alpha/1999-April/000958.html>
Interestingly, he claimed that it was a recently introduced bug, but as
far as I know, the glibc behavior had been unchanged before that.
It seems it was Roland McGrath who pushed for the idea that consistency
wasn't paramound, and that standards conformance was.
<https://sourceware.org/pipermail/libc-alpha/1999-April/002398.html>
Then Drepper did that change, and in his head it was consistent.
<https://sourceware.org/pipermail/libc-alpha/1999-April/000963.html>
It clearly isn't consistent, but it's understandable that he didn't see
it back then.
Wolfram Gloger seemed to be convinced that Drepper's change was
consistent (even if it isn't).
<https://sourceware.org/pipermail/libc-alpha/1999-April/002401.html>
For some reason, nobody in that group analyzed this carefully enough.
I guess it was inertia. We can't blame Drepper (alone) for this bug.
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-08-03 13:51 UTC|newest]
Thread overview: 134+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 21:18 [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-07-31 21:18 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> Alejandro Colomar
2026-07-31 21:23 ` Joseph Myers
2026-07-31 21:28 ` Alejandro Colomar
2026-07-31 21:54 ` Sam James
2026-07-31 22:18 ` Alejandro Colomar
2026-08-01 0:12 ` Alejandro Colomar
2026-08-01 14:43 ` Sam James
2026-07-31 21:51 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) G. Branden Robinson
2026-07-31 21:59 ` on the irresponsibility of pursuing C language reform Sam James
2026-07-31 22:24 ` G. Branden Robinson
2026-07-31 23:19 ` Alejandro Colomar
2026-08-01 14:52 ` Sam James
2026-08-01 12:01 ` Alejandro Colomar
2026-08-01 12:04 ` Alejandro Colomar
2026-08-01 14:38 ` Sam James
2026-08-01 15:15 ` Alejandro Colomar
2026-08-01 16:10 ` Sam James
2026-08-01 17:09 ` Alejandro Colomar
2026-08-01 21:34 ` G. Branden Robinson
2026-08-01 22:22 ` Alejandro Colomar
2026-08-01 22:26 ` Alejandro Colomar
2026-08-03 13:42 ` Joseph Myers
2026-08-03 14:22 ` Alejandro Colomar
2026-08-03 14:38 ` on glibc forking/reclaiming its man pages (was: on the irresponsibility of pursuing C language reform) G. Branden Robinson
2026-08-03 14:44 ` Joseph Myers
2026-08-03 15:18 ` G. Branden Robinson
[not found] ` <CAETFuj2OwoyK9J85r2f0RoXbHbXKA4gQJ=JZ-7=QoqGcMwk0+Q@mail.gmail.com>
2026-08-01 22:44 ` on the irresponsibility of pursuing C language reform Alejandro Colomar
2026-08-01 23:24 ` Alejandro Colomar
2026-08-01 23:53 ` proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) G. Branden Robinson
2026-08-02 0:27 ` Alejandro Colomar
2026-08-02 1:03 ` Alejandro Colomar
2026-08-03 0:47 ` proposed revision to memory.h(3head) Alejandro Colomar
2026-08-03 17:58 ` Mark Harris
2026-08-03 18:47 ` Alejandro Colomar
2026-08-03 20:14 ` Mark Harris
2026-08-03 23:36 ` Alejandro Colomar
2026-08-04 3:25 ` Mark Harris
2026-08-03 14:10 ` proposed revision to memory.h(3head) (was: on the irresponsibility of pursuing C language reform) Joseph Myers
2026-08-03 14:31 ` Alejandro Colomar
2026-08-02 12:52 ` on the irresponsibility of pursuing C language reform Steve Summit
2026-08-02 13:17 ` Alejandro Colomar
2026-08-02 13:45 ` Steve Summit
2026-08-02 14:11 ` Alejandro Colomar
2026-08-02 19:28 ` Paul Eggert
2026-08-02 20:31 ` Alejandro Colomar
2026-08-03 3:28 ` Paul Eggert
2026-08-03 11:39 ` Alejandro Colomar
2026-08-03 13:23 ` Joseph Myers
2026-08-01 20:18 ` G. Branden Robinson
2026-08-01 20:42 ` Alejandro Colomar
2026-08-01 20:45 ` Alejandro Colomar
2026-08-01 20:52 ` G. Branden Robinson
2026-08-01 21:12 ` Alejandro Colomar
2026-07-31 22:10 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:21 ` Alejandro Colomar
2026-07-31 22:28 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 22:42 ` on the irresponsibility of pursuing C language reform (was: [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h>) Joseph Myers
2026-07-31 22:52 ` Alejandro Colomar
2026-07-31 23:11 ` Joseph Myers
2026-07-31 23:32 ` G. Branden Robinson
2026-08-01 12:39 ` Alejandro Colomar
2026-08-01 14:26 ` Christopher Bazley
2026-08-01 15:29 ` Alejandro Colomar
2026-07-31 23:45 ` on the irresponsibility of pursuing C language reform (was: " Alejandro Colomar
2026-08-01 12:39 ` Douglas McIlroy
2026-08-01 19:54 ` G. Branden Robinson
2026-08-01 20:35 ` Alejandro Colomar
2026-07-31 23:08 ` [PATCH 1/2] man/man3/{mem,strn}*(): SYNOPSIS, STANDARDS: Document these as provided by <memory.h> G. Branden Robinson
2026-07-31 23:28 ` Joseph Myers
2026-07-31 23:57 ` G. Branden Robinson
2026-08-01 0:06 ` Alejandro Colomar
2026-07-31 22:05 ` Alejandro Colomar
2026-07-31 22:16 ` Joseph Myers
2026-07-31 22:33 ` Alejandro Colomar
2026-07-31 23:48 ` [PATCH 1/2] man/man3/{mem, strn}*(): " Collin Funk
2026-07-31 23:52 ` Alejandro Colomar
2026-08-01 0:01 ` Alejandro Colomar
2026-08-04 2:35 ` Thorsten Glaser
2026-07-31 21:19 ` [PATCH 2/2] man/man*/{string.3,memory.h.3head}: Move functions to a new page memory.h(3head) Alejandro Colomar
2026-07-31 21:20 ` [PATCH 0/2] alx-0097r1 - <memory.h>, the legitimate header for memcpy(3) et al Alejandro Colomar
2026-08-01 0:25 ` [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h> Alejandro Colomar
2026-08-01 22:22 ` Bruno Haible
2026-08-01 22:38 ` Alejandro Colomar
2026-08-01 22:55 ` Bruno Haible
2026-08-01 23:10 ` Alejandro Colomar
2026-08-01 23:26 ` Collin Funk
2026-08-01 23:34 ` Alejandro Colomar
2026-08-01 23:29 ` Paul Eggert
2026-08-01 23:36 ` Alejandro Colomar
2026-08-02 0:08 ` the Linux man-pages as an educational tool (was: [PATCH v2] man/man3/mem*(): SYNOPSIS: Document non-standard mem*() functions as provided by <memory.h>) G. Branden Robinson
2026-08-02 0:45 ` Alejandro Colomar
2026-08-02 1:04 ` the Linux man-pages as an educational tool Collin Funk
2026-08-02 1:15 ` G. Branden Robinson
2026-08-02 1:15 ` Alejandro Colomar
2026-08-02 1:49 ` Collin Funk
2026-08-02 11:29 ` Alejandro Colomar
2026-08-02 11:47 ` Alejandro Colomar
2026-08-02 12:04 ` Alejandro Colomar
2026-08-02 21:23 ` Maciej W. Rozycki
2026-08-02 21:34 ` Alejandro Colomar
2026-08-02 23:08 ` Arsen Arsenović
2026-08-02 23:10 ` G. Branden Robinson
2026-08-02 23:27 ` Collin Funk
2026-08-02 23:37 ` Alejandro Colomar
2026-08-02 23:41 ` Alejandro Colomar
2026-08-02 23:42 ` Alejandro Colomar
2026-08-03 1:12 ` Alejandro Colomar
2026-08-03 2:09 ` G. Branden Robinson
2026-08-03 12:21 ` Alejandro Colomar
2026-08-03 14:05 ` Sam James
2026-08-03 14:40 ` Alejandro Colomar
2026-08-03 15:34 ` G. Branden Robinson
2026-08-03 16:11 ` Alejandro Colomar
2026-08-03 16:15 ` Sam James
2026-08-03 16:43 ` Alejandro Colomar
2026-08-03 10:28 ` the Linux man-pages as an educational tool... and a bit about C Αγαθοκλής Χατζημανίκας
2026-08-03 14:03 ` the Linux man-pages as an educational tool Sam James
2026-08-03 14:28 ` Alejandro Colomar
2026-08-04 2:39 ` Collin Funk
2026-08-03 16:09 ` on project management (was: the Linux man-pages as an educational tool) G. Branden Robinson
2026-08-03 19:46 ` enh
2026-08-03 21:09 ` on project management Arsen Arsenović
2026-08-02 23:30 ` the Linux man-pages as an educational tool Alejandro Colomar
2026-08-03 11:00 ` Arsen Arsenović
2026-08-03 16:07 ` Jeffrey Walton
2026-08-03 16:17 ` Alejandro Colomar
2026-08-03 19:31 ` Joseph Myers
2026-08-03 19:47 ` Alejandro Colomar
2026-08-03 13:51 ` Alejandro Colomar [this message]
2026-08-03 12:35 ` Bruno Haible
2026-08-03 13:07 ` Alejandro Colomar
2026-08-03 19:45 ` Joseph Myers
2026-08-03 19:50 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anCXCl5QbkDjsGzl@devuan \
--to=alx@kernel.org \
--cc=bug-gnulib@gnu.org \
--cc=collin.funk1@gmail.com \
--cc=eggert@cs.ucla.edu \
--cc=g.branden.robinson@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=macro@orcam.me.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox