On 2016.12.20 at 10:32 -0800, h...@zytor.com wrote: > On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf > <mar...@trippelsdorf.de> wrote: > >On 2016.12.20 at 03:10 -0800, H. Peter Anvin wrote: > >> On 12/20/16 02:00, Markus Trippelsdorf wrote: > >> > On 2016.12.20 at 01:30 -0800, H. Peter Anvin wrote: > >> >> I'd strongly prefer a non-data-dependent solution, specifically > >adding > >> >> at the top of sort_relocs(): > >> >> > >> >> if (!r->count) > >> >> return; > >> >> > >> >> However, by my reading of the C and POSIX standards, this is a gcc > >> >> error: qsort() should do nothing if the count is zero. > >> > > >> > No, it is invoking undefined behavior. > >> > >> > Notice the nonnull attribute in /usr/include/stdlib.h: > >> > > >> > 739 /* Sort NMEMB elements of BASE, of SIZE bytes each, > >> > 740 using COMPAR to perform the comparisons. */ > >> > 741 extern void qsort (void *__base, size_t __nmemb, size_t __size, > >> > 742 __compar_fn_t __compar) __nonnull ((1, 4)); > >> > > >> > But feel free to revert my patch and add your solution. > >> > >> Well, s/gcc/glibc/ then. > >> > >> > The qsort() function shall sort an array of nel objects, > >the > >> > initial element of which is pointed to by base > > > >NULL does not point to any object, therefore it is UB. > > That seems, quite frankly, like a pretty idiotic lawyerism. > Why would a pointer that by spec is never referenced not be able to be null?
Thank you. Let me quote the standard for you: 7.1.4 »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 promotion) not expected by a function with variable number of arguments, the behavior is undefined.« 7.24.1(2) »Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero […] pointer arguments on such a call shall still have valid values, as described in 7.1.4.« The same applies to memcpy, etc. The compiler can assume that these pointers are not NULL and optimizes accordingly. -- Markus
