Thanks for the explanation! On 2026-07-29 Paul Eggert wrote: > In practice, though, many implementations treat that list's entries > as extensions, not as retroactive changes. For example, I just now > checked and N2829 does not work with GCC in C17 mode, despite being a > "retroactive change" to C17. This means that despite the informal > intent that these are clarifications, we can't assume platforms > conforming to older C standards will support the changes.
glibc's <assert.h> checks if the compiler is in C23 mode. In a way it's unfortunate, but the upside is that it's harder to accidentally write code that doesn't build with a C17 toolchain on an older system. In contrast, memcpy(ptr, NULL, 0) will build, so applying N3322 in pre-C2y modes feels like a reliability or security improvement. > As a practical matter, it now seems clear that portable code can't > assume that memcpy(0,0,0) always works in platforms claiming > conformance to C23, Right. gnulib-readme.texi could say "C2y will be the first C standard" instead of "C23 was". -- Lasse Collin
