sparc: fix for missing include file

[Paul Eggert]

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.