Date: Tue, 20 Dec 2016 20:31:53 +0100
From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: hpa@zytor.com
Cc: tglx@linutronix.de, linux-kernel@vger.kernel.org, mingo@kernel.org,
        linux-tip-commits@vger.kernel.org
Subject: Re: [tip:x86/urgent] x86/tools: Fix gcc-7 warning in relocs.c
Message-ID: <20161220193153.GE289@x4>
References: <20161215124513.GA289@x4>
 <tip-7ebb916782949621ff6819acf373a06902df7679@git.kernel.org>
 <c6f83231-9847-3f41-6743-325248ffc451@zytor.com>
 <20161220100056.GA289@x4>
 <2966d559-2cea-fd95-76d4-df34192a9b88@zytor.com>
 <20161220115109.GB289@x4>
 <20577F06-9AE8-4760-9F38-45711025D6FB@zytor.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20577F06-9AE8-4760-9F38-45711025D6FB@zytor.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2287
Lines: 59

On 2016.12.20 at 10:32 -0800, hpa@zytor.com wrote:
> On December 20, 2016 3:51:09 AM PST, Markus Trippelsdorf <markus@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