Tom Lane via tz said:
7.1.4 Use of library functions
[#1] Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: 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 type (after promotion) not expected by a ^^^^^^^^^^^^ function with 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.
There's a faction that thinks that the underlined comment entitles every libc function to halt-and-catch-fire when passed a null pointer.
They're right.
Never mind whether a nearby zero count argument clearly forbids it from making any memory accesses associated with that pointer, as expressed by the immediately following sentence.
No, because the implementation might do something like: endptr = (unsigned char *) base + nmemb * size; before (or after) checking the value of nmemb.
I side with Winston Churchill in saying "this is nonsense up with which I shall not put".
Actually, he didn't say it.
There are no useful grounds for claiming that qsort, memset, memcpy, etc, with a null pointer and a zero count argument should be undefined.
There are, or were, implementers who disagree with you. -- Clive D.W. Feather | If you lie to the compiler, Email: clive@davros.org | it will get its revenge. Web: http://www.davros.org | - Henry Spencer Mobile: +44 7973 377646