Guy Harris via tz <tz@iana.org> writes:
On Oct 25, 2022, at 9:34 PM, Jonathan Leffler via tz <tz@iana.org> wrote:
I see nothing in the C standard specification of qsort() that says sorting an array with zero members leads to undefined behaviour.
I see nothing in C90 through C18 that explicitly say anything about passing NULL as base and 0 as nmemb.
Refreshing my memory about this ... I think the argument hinges on this bit in C99, which applies to all C-specified library functions: 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. 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. I side with Winston Churchill in saying "this is nonsense up with which I shall not put". There are no useful grounds for claiming that qsort, memset, memcpy, etc, with a null pointer and a zero count argument should be undefined. It's merely a gotcha for the unwary programmer. C had a similar gotcha back in the nineties for integer division with negative values ... which they eventually fixed. This needs to get fixed in the language standard, not worked around forevermore. regards, tom lane