This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sparc: fix for missing include file

On 13 December 2014 at 20:00, Paul Eggert <> 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

Will Newton
Toolchain Working Group, Linaro

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]