This is the mail archive of the libc-alpha@sourceware.org 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


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.

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 pragma-ize it.


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