Vincent Lefevre wrote, on 11 Sep 2024: > > 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.
Effectively it does. It's implied by the phrase "unless explicitly stated otherwise". > 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. The ERRORS section describes some of the function's behaviour and therefore constitutes part of the description of the function. Don't conflate the generic word "description" with the section name "DESCRIPTION". -- Geoff Clare <g.cl...@opengroup.org> The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England
