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: Pádraig Brady
Subject: bug#11675: stty bad C semantics
Date: Tue, 12 Jun 2012 00:47:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0

On 06/11/2012 09:29 PM, Paul Eggert wrote:
> This area is a bit of a mess in the standard, but I think
> Edward Schwartz is right that initializers of auto variables
> are not guaranteed to clear padding.
> 
> As I understand it under Eric Blake's interpretation, a
> complete initializer for an auto variable is not guaranteed
> to clear the padding, but an incomplete initializer is
> guaranteed to do so.  This would be pretty strange.

I agree with Eric's interpretation.

There are ambiguous statements in the standard,
but IMHO the _init_ requirement (C99 6.7.8 para. 21)
trumps the _assignment_ requirement (6.2.6.1#6).

I see it as a language standard way to init auto vars,
so that they match static vars of the same type,
and so can be compared.

http://www.pixelbeat.org/programming/gcc/auto_init.html

> I think Edward's interpretation of the incomplete-initializer
> wording is more likely to be the correct one: namely, that
> missing initializers are treated as if they were zero.
> 
> Even if the standard was intended to clear the padding,
> clearly in practice we have an implementation that doesn't
> do so, and it no doubt performs better that way, so I'd say
> something like Edward's patch is advisable.

Well we've not had an issue in nearly 6 years with the existing form:
http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e245a66

If this was an isolated statement then I'd change for pragmatic reasons,
but since it touches multiple places in the code I'd suggest
patching coreutils locally (with essentially the reverse of the above),
until CIL is fixed to conform to the standard.

cheers,
Pádraig.





reply via email to

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