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


From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 13 Dec 2014 12:00:09 -0800

> 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.

The destination is not necessarily NULL terminated, I see nothing
in the definition of this function that says so.

In fact, if anything, we are required to execute this step and put
that sole and only NULL terminating charater into the destination if
'n' is passed as zero.

The only reasonable thing to do, therefore, is to explicitly
initialize 'c' to '\0', and not with some conditional LINT'ish
thing.

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