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

[Aurelien Jacobs]

Uoti Urpala wrote:

> 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.

I doubt that any implementation will have wrong behavior apart from
the wrong result. But I guess you are theoretically right.

> > 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).

That's a micro-optimization, but this code is indeed not
performance-critical.

Anyway, I don't care much about this, so I will change it if it please
you.

Aurel