Re: sparc: fix for missing include file

[Will Newton <will dot newton at linaro dot org>]

On 13 December 2014 at 20:00, Paul Eggert <eggert@cs.ucla.edu> wrote:
> David Miller wrote:
>
>>>> >>strncat.c: In function âstrncatâ:
>>>> >>strncat.c:76:6: error: âcâ may be used uninitialized in this function
>>>> >>[-Werror=uninitialized]
>>>
>>> ...
>>> >That's amusing, since the code works regardless of whether 'c' is
>>> >initialized properly, assuming that using an uninitialized value
>>> >doesn't trap or have similarly bad behavior....
>>
>> How does the code "work"?  The test of 'c' against '\0' at the end of
>> the function happens even if 'n' is passed as zero in which case 'c'
>> will not be initialized at all.
>
>
> Sure, but the result of the test doesn't matter, because in that case the
> code:
>
>   if (c != '\0')
>     *++s1 = '\0';
>
> possibly assigns zero to a location that is already zero.  That is, in the
> case you mention this code is a no-op no matter what c's value is.  It's
> pretty funny.
>
> True, the code is relying on behavior that is undefined, since the C
> standard says using an uninitialized variable has undefined behavior.  But I
> don't know of any libc platforms where the code doesn't work, and since our
> general rule has been to not slow down glibc to pacify GCC, the usual gaggle
> of pragmas are needed here.

Loading a zero constant into c is cheap and the side effect of the
undefined behaviour is potentially a write to memory so it is not
always going to be a performance win to do this. Also potentially
runtime analysis tools (e.g. sanitizers, valgrind) may trip over this
so it seems to me a better idea just to not invoke undefined
behaviours.

-- 
Will Newton
Toolchain Working Group, Linaro