This is the mail archive of the
mailing list for the glibc project.
Re: sparc: fix for missing include file
- From: Will Newton <will dot newton at linaro dot org>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: David Miller <davem at davemloft dot net>, Ondrej Bilka <neleai at seznam dot cz>, wbx at openadk dot org, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 15 Dec 2014 09:34:29 +0000
- Subject: Re: sparc: fix for missing include file
- Authentication-results: sourceware.org; auth=none
- References: <20141211 dot 150535 dot 106178897111220975 dot davem at davemloft dot net> <20141213 dot 130022 dot 1182209281374969366 dot davem at davemloft dot net> <548C8EBF dot 6010003 at cs dot ucla dot edu> <20141213 dot 143210 dot 2082290151274481189 dot davem at davemloft dot net> <548C9AC9 dot 8020608 at cs dot ucla dot edu>
On 13 December 2014 at 20:00, Paul Eggert <firstname.lastname@example.org> wrote:
> David Miller wrote:
>>>> >>strncat.c: In function âstrncatâ:
>>>> >>strncat.c:76:6: error: âcâ may be used uninitialized in this function
>>> >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
> 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
Toolchain Working Group, Linaro