On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf <markus@xxxxxxxxxxxxxxx> 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? -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
|