glibc misc/sys/cdefs.h nonull - typo in comment

[Jonny Grant]

On 29/10/2023 05:24, Paul Eggert wrote:
> On 2023-10-28 16:50, Jonny Grant wrote:
>> Could you give an example of a POSIX API text you refer to that specifies many arguments should not be NULL?
> 
> "If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer), the behavior is undefined."
> 
> https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/functions/V2_chap02.html#tag_15_01_01

Thank you for sharing the link. Yes, I've seen that everything not detailed on a particular function description would be UB.

glibc does go beyond POSIX and set errno to EFAULT if a null pointer constant is passed.
https://man7.org/linux/man-pages/man2/olduname.2.html

Although I looked at glibc/posix/uname.c and it has EINVAL there, couldn't spot where the EFAULT comes from, probably there is another file.

The POSIX pages don't specify any error checking for uname().
https://man7.org/linux/man-pages/man3/uname.3p.html
https://pubs.opengroup.org/onlinepubs/009604599/functions/uname.html

It might be too difficult to get behaviors described for the null pointer constant in the POSIX standard for something like uname().

Other functions do check parameters, like the way write() checks fd, and setting errno EBADF if it's not a valid file descriptor.

> 
> This wording is copied from the C Standard.
> 
> 
> The April 2023 working draft of C23 has adjusted the wording to be the following, and I expect POSIX to follow suit eventually. Notice the new restrictions:
> 
> "If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after default argument promotion) not expected by a function with a variable number of arguments, the behavior is undefined.
> 
> "If a function argument is described as being an array, the pointer actually passed to the function shall have a value such that all address computations and accesses to objects (that would be valid if the pointer did point to the first element of such an array) are in fact valid.[210]
> 
> "[210] This includes, for example, passing a valid pointer that points one-past-the-end of an array along with a size of 0, or using any valid pointer with a size of 0."

It is good it is being clarified further.