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
