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
