bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11675: stty bad C semantics


From: Eric Blake
Subject: bug#11675: stty bad C semantics
Date: Mon, 11 Jun 2012 13:50:06 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1

On 06/11/2012 01:16 PM, Edward Schwartz wrote:
> Hi,
> 
> I think there is a bug in main() of stty in coreutils 8.17.  The gist
> of the problem is that two structures are initialized:
> 
>    struct termios mode = { 0, };
> 
> and
> 
>   struct termios new_mode = { 0, };
> 
> They are then both modified, and then compared with memcmp.  The
> problem is that the structs contain padding bytes.  The C99 standard
> says "The value of padding bytes when storing values in structures or
> unions (6.2.6.1)." is unspecified, so the padding bytes may not be set
> to zero.

I disagree with your interpretation of C99, and claim instead that your
CIL compiler is buggy.

C99 6.7.8 para. 21:

"If there are fewer initializers in a brace-enclosed list than there are
elements or members of an aggregate, or fewer characters in a string
literal used to initialize an array of known size than there are
elements in the array, the remainder of the aggregate shall be
initialized implicitly the same as objects that have static storage
duration."

And while there is no way to zero out padding bits by direct assignment,
I think we _are_ guaranteed that padding bits are zero when doing the
same initialization as static storage duration if we did not call out
all the named members.

> The problem is easily fixed by using memset, instead of implied
> initializations.  I am attaching a patch that does this.  While it
> won't affect most coreutils users, it might save some time for someone
> using a non-standard compiler or analysis platform.

If I understand correctly, gcc is also able to optimize out the memset,
so that your patch has no net impact and would allow us to work around
your buggy compiler; but I will leave it up to Jim whether it is worth
applying.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]