On 2026-07-31 14:34, Bruno Haible wrote:
Lasse has already done a large part of the testing work.
I guess I don't have quite the confidence that the testing work is close to
done.
And part of this is it sounds like my goals weren't the same. Mine was to
guarantee a small extra element of software safety by ensuring N3322 semantics,
whereas the current Gnulib goal, I guess, is more modest, namely, to scout for
implementations that obviously don't conform to N3322.
So, IMO, what we can aim for, here, is:
- Enhance the unit tests.
- Refine the #if conditions: Replace 2.45 with 2.99, maybe add an
__STDC_VERSION__ test to the __GNUC__ and __GNUC_MAJOR__ condition.
There are many compiler configurations out there - some that don't even exist
yet. And our tests are not likely to be complete enough to check for all
plausible failures in this area.
- In gnulib-readme.texi say that portable code should not assume N3322, other
than assuming that NULL + 0 works.
Yes, that's prudent. Done via the attached patch.
Then, 10 years from now, users can judge from the #if conditions whether they
can assume N3322 or not.
I suspect that ten years from now it'll still be dicey in general, and there
still won't be a good way for users to see whether their guess is right if they
guess the riskier approach of assuming N3322 in their apps. The more prudent
approach would be to follow the advice in the attached patch, namely, don't
assume most of N3322. With that in mind, we might want to reconsider Gnulib's
current redeclarations of memcpy etc., as they're likely to make it harder to
follow that advice.
From ca3174cadad8bc5573448464afe46bb05adb9a92 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email protected]>
Date: Fri, 31 Jul 2026 18:24:29 -0700
Subject: [PATCH] doc: N3322 cautions
* doc/gnulib-readme.texi (Other portability assumptions):
Add cautions about other parts of N3322.
---
ChangeLog | 4 ++++
doc/gnulib-readme.texi | 16 +++++++++++++---
2 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4b80907ea7..927193826c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,9 @@
2026-07-31 Paul Eggert <[email protected]>
+ doc: N3322 cautions
+ * doc/gnulib-readme.texi (Other portability assumptions):
+ Add cautions about other parts of N3322.
+
link, symlink: more errno portability issues
* doc/posix-functions/link.texi:
* doc/posix-functions/linkat.texi:
diff --git a/doc/gnulib-readme.texi b/doc/gnulib-readme.texi
index 103e2e61f0..96823b18cd 100644
--- a/doc/gnulib-readme.texi
+++ b/doc/gnulib-readme.texi
@@ -574,10 +574,20 @@ Adding zero to a null pointer does not change the pointer.
For example, @code{0 + (char *) NULL == (char *) NULL}.
Similarly, subtracting zero does not change a null pointer,
and subtracting two null pointers results in zero.
-C23 was the first C standard to require this behavior; see
+C2y is planned to be the first C standard to require this behavior; see
``@url{https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3322.pdf,
-Allow zero length operations on null pointers}'', WG14 N3322 (2024-08-28);
-which was adopted retroactively for C23.
+Allow zero length operations on null pointers}'', WG14 N3322 (2024-08-28).
+
+However, portable code should not assume the other parts of N3322.
+For example, although N3322 requires that functions like @code{memcpy}
+succeed on null pointers when the size is zero,
+many C23-and-earlier platforms do not conform to this requirement
+because their compilers or library declarations
+assume that arguments to @code{memcpy} must be non-null.
+Although Gnulib has some tests for N3322 conformance,
+these tests are incomplete and it is doubtful that they could be made
+complete enough to be trustworthy for all plausible applications and
+C23-and-earlier compilers, so caution is advised in this area.
@end itemize
@end itemize
--
2.53.0
