[FFmpeg-cvslog] r11573 - trunk/libavformat/mxf.c
Sun Jan 20 02:00:36 CET 2008
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 18.104.22.168 6.
More information about the ffmpeg-cvslog