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

Rich Felker dalias
Sun Jan 20 07:23:39 CET 2008


On Sun, Jan 20, 2008 at 03:42:36AM +0200, Uoti Urpala wrote:
> 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.

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

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

Rich




More information about the ffmpeg-cvslog mailing list