This is the mail archive of the
mailing list for the glibc project.
Re: sparc: fix for missing include file
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: David Miller <davem at davemloft dot net>
- Cc: neleai at seznam dot cz, wbx at openadk dot org, libc-alpha at sourceware dot org
- Date: Sat, 13 Dec 2014 12:00:09 -0800
- 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>
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 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
Another amusing tidbit: this is not the only part of string/strncat.c that
relies on undefined behavior. The earlier statement 's1 -= 1;' does so as well,
it's just that GCC doesn't diagnose the earlier statement so we don't need to