When and why realloc(,0) was broken in glibc in 1999

--6uoa3fi5m5ljhc74
Content-Type: text/plain; protected-headers=v1; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
From: Alejandro Colomar <[email protected]>
To: "Maciej W. Rozycki" <[email protected]>
Cc: Collin Funk <[email protected]>, 
	"G. Branden Robinson" <[email protected]>, Paul Eggert <[email protected]>, [email protected], 
	[email protected], [email protected]
Subject: When and why realloc(,0) was broken in glibc in 1999
Message-ID: <anCXCl5QbkDjsGzl@devuan>
References: <am50AM0bdufHa9W3@devuan>
 <15288158.RDIVbhacDa@cagnes>
 <am56ZBzNM5J07AUa@devuan>
 <[email protected]>
 <am6CnOddgaM10pry@devuan>
 <20260802000833.zpu27l7ibvrbouna@illithid>
 <am6PkypxYg-Fq4Iz@devuan>
 <[email protected]>
 <am6X32HkGdm2xTd7@devuan>
 <[email protected]>
MIME-Version: 1.0
In-Reply-To: <[email protected]>

Hi Maciej,

> Date: 2026-08-02 22:23:36+0100
> From: "Maciej W. Rozycki" <[email protected]>
>
> On Sun, 2 Aug 2026, Alejandro Colomar wrote:
>=20
> >      The  original implementation in glibc would have been con=E2=80=90
> >      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=E2=80=90contra=
=E2=80=90
> >      dicting).
>=20
>  Well, this was a period when glibc was driven by personal preferences of=
=20
> one particular maintainer, so I don't think it is a good example in this=
=20
> 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

--=20
<https://www.alejandro-colomar.es>

--6uoa3fi5m5ljhc74
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmpwnNsACgkQ64mZXMKQ
wqllshAAvNk+TAf3R0Pjnx5C/B+e4tui2g1gEZ/yEriA7wkji3CDk4wCTcKXt4Mk
bTwoLqyEc270ZRlZYxKBWi1Mjns2uNpwMcYcHjYLMnt6tzJz7Oj3COfQKrmY0p3T
9Ki4+I6UxXkLMWCyBjm6+AJjLnHl1gNmNmSHIhcaX/FlqffQ7Nq3ruFWwLGrxhYj
CtDhWE/saBq90mLpF3Mut355h/NSCbol3WMPB+A8KKQviN107KlF1D43o07/5K5k
ApTOYtdN8ME9d9HFM77ZHocqO+jj4UxVIkEptA6ykX5pA2hZ4MHxme85XH9GvNSC
AUXWCstgAS4jqOvwJXLIUbJUL+C6fTZdInQZav/XJWLvxbFG1kB6wfsVkjzDOmqW
1kk8PefB9Chc6h1EQdkaUzE6BPf6LNzkTYExauDjbpUVeaTcis6v1ZYzx9Vhj+lO
vpu5kdhwR+LydWRJwDH13KWvG2tDId+ulJIJk07LOYAgFF+kEKx2Wo8G2GMeP/xo
kLaPZ5JxKa5pjzh8FIJ3IbLFkLhdUv93iBSe4FZ/Hn2BWtzuv9aQo3RRwiGlgR/T
AOfGgZa62PgenCwdaxrcw1L1Xt+kE90J7NfAoPj16dLFlwv4zQkeV4OdcNhNAW+f
AoqBbAbDeJ4L09AVZtnxyv+RDnqxUkZTZeyhpGXYDfYiOpQ4D7M=
=Y8o7
-----END PGP SIGNATURE-----

--6uoa3fi5m5ljhc74--