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

Måns Rullgård mans
Sun Jan 20 01:13:00 CET 2008


Rich Felker <dalias at aerifal.cx> writes:

> On Sat, Jan 19, 2008 at 09:50:18PM +0000, M?ns Rullg?rd wrote:
>> >> >> -        UID uid;
>> >> >> +        UID uid = {0};
>> >> >
>> >> > I'm quite sure it does not matter here, but note that even for
>> >> > arrays as small as 16 bytes memset is quite a bit faster than
>> >> > this kind of initialization, at least with gcc around 3.4
>> >> 
>> >> If memset is the fastest way, gcc should know to call it in such
>> >> situations.  I've seen gcc generate memcpy() calls for struct
>> >> assignments, so it's certainly something that is reasonable to expect.
>> >
>> > Certainly gcc should know, back then it didn't though (I noticed it
>> > while optimizing libfaad back then).
>> 
>> If recent gcc versions get it right, I see no reason to obfuscate the code.
>
> 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.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-cvslog mailing list