[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65bc2156-fb06-49b8-29f1-b6df8d98ed6d@mirbsd.de>
Date: Thu, 19 Jun 2025 17:38:15 +0200 (CEST)
From: Thorsten Glaser <tg@...bsd.de>
To: musl@...ts.openwall.com
cc: Alejandro Colomar <alx@...nel.org>, linux-man@...r.kernel.org,
libc-alpha@...rceware.org, Paul Eggert <eggert@...ucla.edu>,
Bruno Haible <bruno@...sp.org>, bug-gnulib@....org
Subject: Re: [v2] malloc.3: Clarify realloc(3) standards conformance
On Thu, 19 Jun 2025, Rich Felker wrote:
>> + The glibc implementation of realloc() is not consistent with
>> + that, and as a consequence, it is dangerous to call
>> + realloc(p, 0) in glibc.
>
>It's not dangerous if you know what it's doing. Rather it's
>non-portable.
Nope.
It’s actually dangerous in all libcs.
GCC is a repeat offender of taking things that are Undefined
Behaviour in C (and GCC 15 even defaults to C23) and optimising
in a way that breaks programs and libraries that depend on the
behaviour of the respektive system and libc, which they even
guarantee.
This is an unperiodic reminder that GCC lacks a -std=posix2024
and similar.
This is also why I was a bit angry that C23 made it UB. Had
they made it unspecified (POSIX verbiage) / IB (C verbiage),
implementations could actually do things and compilers would
not be allowed to break things that rely on it, i.e. it would
merely have been unportable. But when ISO C says UB it’s not
unportable, it’s dangerous.
bye,
//mirabilos
--
<ch> you introduced a merge commit │<mika> % g rebase -i HEAD^^
<mika> sorry, no idea and rebasing just fscked │<mika> Segmentation
<ch> should have cloned into a clean repo │ fault (core dumped)
<ch> if I rebase that now, it's really ugh │<mika:#grml> wuahhhhhh
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
