Re: N3322 functionality tests

Bruno Haible via Gnulib discussion list <[email protected]> Fri, 31 Jul 2026 23:34:10 +0200
Newsgroups gmane.comp.lib.gnulib.bugs
Message-ID <5857873.GXAFRqVoOG@cagnes>
Paul Eggert wrote:
> The more I think about this, the more I think our current approach is too risky and has too little benefit for the risk. We are barking up the wrong tree.
> 
> Instead, aside from documenting the N3322 issue, we should do either of the following:
> 
> * In gnulib-readme.texi say that portable code should not assume N3322, other than assuming that NULL + 0 works.
> 
> * Implement a new Gnulib module null-length-0, which supports the rest of N3322, the part that says standard functions support the idea of null pointers with length 0.
> 
> If we do the former, we should disable our test cases for null pointers of length 0, unless perhaps 202311 < __STDC_VERSION__. If we do the latter, those test cases should be enabled only if the null-length-0 module is in use.
> 
> If we do the latter, null-length-0 should be conservative: it should assume that the current platform does not support N3322 unless we know for sure otherwise (and right now, we don't really know otherwise, for any platform). No Gnulib modules should depend on null-length-0 for now, as this stuff is still too unreliable. The null-length-0 module can operate by replacing the affected functions.

Why should that be an "either — or"?

The current approach that we use for unportable features, where a workaround
is impossible or too heavy, is:

  - Test the feature through unit tests.
  - Disable the particular test cases on platforms where they fail.
    (We can test the platforms on the compilefarm machines and also on the
    GitHub CI machines.)
  - Use this knowledge to document the portability limitations of the feature.

This approach works fine, even though it is initially a bit of work. See e.g.
  tests/test-fenv-except-trapping-2.c
  tests/test-c32ispunct.c
In this case, Lasse has already done a large part of the testing work.

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.

  - In gnulib-readme.texi say that portable code should not assume N3322, other
    than assuming that NULL + 0 works.

  - No 'null-length-0', that's overkill.

  - No replacement of memcpy etc., that's overkill as well.

Then, 10 years from now, users can judge from the #if conditions whether they
can assume N3322 or not.

Bruno