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

[Uoti Urpala]

On Sat, 2008-01-19 at 20:19 -0500, Rich Felker wrote:
> On Sun, Jan 20, 2008 at 03:00:36AM +0200, Uoti Urpala wrote:
> > It's not guaranteed to work in any practical use case I see. How do you
> > get a struct where the padding bytes are guaranteed to be 0? You can get
> > an all-zeros struct with memset, but you'll have a hard time filling any
> > fields to useful values without making the padding bytes unspecified
> > again (it's in principle possible by taking the address of a field and
> > then using that as a pointer, but...). I think you're not aware of C
> > standard part 6.2.6.1 6.
> 
> You misread the statement of 6.2.6.1 6. It says that in cases like:
> 
> struct foo a, b;
> a = b;
> 
> the padding bytes of a will contain unspecified values. It does NOT
> say that
> 
> a.x = b.x;
> 
> can fill padding bytes of a (unless they are also padding bytes of
> a.x) with unspecified values.

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.

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

> This is exactly why I said memcpy is
> better -- it has more tightly defined behavior than structure
> assignments.

There's no reason why more tightly defined behavior would automatically
be better.