On 2026-02-21T01:47:21+0100, Alejandro Colomar wrote: > Hi Paul, > > On 2026-02-20T16:31:44-0800, Paul Eggert wrote: > > On 2026-02-20 16:04, Alejandro Colomar wrote: > > > > > BTW, the it doesn't really need __STDC_VERSION__ >= 202311L. This works > > > all the way back to C11, AFAIK. > > > > Gnulib doesn't assume C11; it assumes only C99. We may start assuming a > > later C at some point but now is not a good time. > > Yup, I didn't mean we don't need any cpp(1) check, but that we don't > need C23. We could put a C11 test. > > > > > > However, shouldn't that be done in a separate patch? > > > > Not quite following, but if you mean this sort of thing affects existing > > functions other than the proposed strnul, then yes that patch should be done > > first. As Bruno notes, though, it's not clear what those other functions > > would be, as we should leave strchr etc. alone. > > Okay. And if we don't make strchr(3) etc. const-generic, do you want to > make strnul() const-generic? I'm not sure; on the one hand, it would > be useful; on the other, it might be confusing why gnulib provides such > APIs for some functions but not for others. In any case, it's up to > you. > > If you prefer it const-generic, I think it would be easier if you write > the patch; you know what you can and can't use within gnulib, so you'll > do it faster.
BTW, another way to implement it as a const-generic macro would be
#define strnul(s) \
({ \
__auto_type s_ = s; \
\
s_ + strlen(s_); \
})
You'd have to pick a unique variable name to make sure it doesn't
collide with any user variable. But you could do that. It would be way
simpler than implementing something with _Generic(). And it would work
even in C++, I guess.
Cheers,
Alex
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
