[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