On 2024-09-11 09:03:28 +0100, Geoff Clare via austin-group-l at The Open Group wrote: > Vincent Lefevre wrote, on 11 Sep 2024: > > > > On 2024-09-10 14:32:32 +0100, Geoff Clare via austin-group-l at The Open > > Group wrote: > > > I can see that my earlier statement was a bit misleading. There doesn't > > > need to be an explicit statement that passing a null pointer is allowed, > > > just something that overrides that quoted text from 2.1.1. > > > > > > The relevant part of 2.1.1 is of the form "unless explicitly stated > > > otherwise ... the behavior is undefined". Any text that defines the > > > behaviour for a null pointer is sufficient to override this. > > > > The case strnlen(0,0) is well defined by the strnlen description: > > the result is necessarily 0. > > > > So it is valid, isn't it? > > No. The strnlen description doesn't mention null pointers, so it > doesn't override the statment about null pointers in 2.1.1.
2.1.1 does not say that null pointers have to be mentioned. And in either case, it is not explicitly stated that a null pointer is *allowed*. All that one can say is that in both cases, the behavior is specified if the null pointer is used. Note that there is a similar issue with the bind() function. https://pubs.opengroup.org/onlinepubs/9799919799/functions/bind.html Nowhere in the description a null pointer is even mentioned or its behavior specified. However, its ERRORS section has [EDESTADDRREQ] or [EISDIR] The address argument is a null pointer. while the behavior implied by the description is supposed to be undefined. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
