[FFmpeg-cvslog] r11573 - trunk/libavformat/mxf.c

[Uoti Urpala]

On Sun, 2008-01-20 at 01:23 -0500, Rich Felker wrote:
> On Sun, Jan 20, 2008 at 03:42:36AM +0200, Uoti Urpala wrote:
> > I read "When a value is stored in an object of struct or union type,
> > including in a member object" to mean that the things which qualify as
> > "storing a value" and thus make all padding bytes of the object
> > unspecified include storing a value in a member.
> 
> "When a value is stored in an object of type struct or union" means
> when the LHS of an assignment operator is a struct or union.

That would be a plausible reading for the part without the
clarification; however changing a member changes the value of the struct
too so it's not like this would be the only reading even without the
added part.

>  If they
> meant to say "When a value is stored in a member of an object of type
> struct or union" then they would say that.

But that's not what anyone meant to say - it's not _limited_ to changing
a member at a time. And "When a value is stored in an object of
structure or union type, or when a value is stored in a member of an
object of type struct or union" isn't so good any more. 

> > What is your alternative reading, and what do you think "including in a
> > member object" refers to? You think it would only be there to clarify
> 
> "Including a member object" means that the rule applies to a struct or
> union which is itself a member of another struct or union.
> 
> > that the padding becomes unspecified also when the struct being looked
> > at is a member of something else? I see no reason why that case would be
> > mentioned separately.
> 
> The standard quite frequently makes this kind of redundant statement.

But usually in cases which are less obvious. Why would anyone think that
having the struct be a member of another would change these rules? The
standard doesn't contain stuff like "i=a assigns the value of a to i,
including in the case where a=42".


Allowing padding bytes to change when any fields change does make sense.
Consider architectures which only access memory a machine word at a
time. When changing a small struct field this may require loading a
larger part of the struct, manipulating it and then writing it back.
Allowing the padding bytes to change means the manipulations need not be
done in a way which would preserve existing padding bytes. Also when you
have a struct like {int a; char b; int c;} a write to .b can be done as
an int-sized write which will overwrite any original padding bytes
around the field.