linux-kernel - Re: [tip:x86/urgent] x86/tools: Fix gcc-7 warning in relocs.c

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20577F06-9AE8-4760-9F38-45711025D6FB@zytor.com>
Date:   Tue, 20 Dec 2016 10:32:58 -0800
From:   hpa@...or.com
To:     Markus Trippelsdorf <markus@...ppelsdorf.de>
CC:     tglx@...utronix.de, linux-kernel@...r.kernel.org, mingo@...nel.org,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86/tools: Fix gcc-7 warning in relocs.c

On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf <markus@...ppelsdorf.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?
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.