[FFmpeg-cvslog] r12253 - trunk/libavformat/matroskaenc.c

Uoti Urpala uoti.urpala
Wed Feb 27 00:33:30 CET 2008


On Wed, 2008-02-27 at 00:11 +0100, Aurelien Jacobs wrote:
> Uoti Urpala wrote:
> > Wouldn't it make more sense to write the tests in the opposite order,
> > to avoid invoking undefined behavior?
> 
> It's not exactly undefined behavior. It's undefined result for the >>
> operation. So either the result is 0 and thus it's what's expected,
> either it's non-zero and the bytes<8 will still end the loop.
> There is no overall undefined behavior here.

There is no such term as "undefined result" separate from "undefined
behavior". If something is undefined behavior (and this is according to
the C standard) then it's free to crash the process, generate writes to
random memory addresses etc. On x86 that will not happen, but OTOH it
makes no sense to talk about any kind of "undefined" when considering
the specific x86 behavior (unless the compiler makes optimizations based
on the assumption that undefined behavior will not be invoked - but if
this happens then the effect will again likely affect more than just the
result of the operation).

> Now, most of the time, the condition which will end the loop is
> val >> bytes*8, so better check it first.

I doubt this is performance-critical enough for that to matter (and if
it is then it could be optimized more efficiently).





More information about the ffmpeg-cvslog mailing list