This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: sparc: fix for missing include file
- From: David Miller <davem at davemloft dot net>
- To: eggert at cs dot ucla dot edu
- Cc: neleai at seznam dot cz, wbx at openadk dot org, libc-alpha at sourceware dot org
- Date: Sat, 13 Dec 2014 15:31:42 -0500 (EST)
- Subject: Re: sparc: fix for missing include file
- Authentication-results: sourceware.org; auth=none
- References: <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>
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.