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

[Rich Felker]

On Sun, Jan 20, 2008 at 03:00:36AM +0200, Uoti Urpala wrote:
> On Sat, 2008-01-19 at 19:25 -0500, Rich Felker wrote:
> > On Sun, Jan 20, 2008 at 12:13:00AM +0000, M?ns Rullg?rd wrote:
> > > > For structs, memset and memcpy are much better than assignment or
> > > > initialization, which are not guaranteed to zero out any padding. This
> > > > is not an issue of implementation but of what the C language itself
> > > > guarantees.
> > > 
> > > If there is padding in a struct, those bytes should never be
> > > explicitly read or written anyway, so it does not matter whether they
> > > are initialised.  Code that depends in any way whatsoever on the value
> > > of padding bytes is *broken*.  It may of course be faster to zero/copy
> > > everything, but that is, as you say, up to the implementation.
> > 
> > Using memcmp for structure comparison is valid, but only as long as
> > you zero the padding bytes first.
> 
> 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. This is exactly why I said memcpy is
better -- it has more tightly defined behavior than structure
assignments.

Rich