[FFmpeg-cvslog] r21069 - trunk/libavcodec/alsdec.c

[Uoti Urpala]

On Sat, 2010-01-09 at 13:51 +0000, M?ns Rullg?rd wrote:
> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> 
> > On Sat, 2010-01-09 at 12:42 +0000, M?ns Rullg?rd wrote:
> >> OK, here's what's happening.
> >> 
> >> When opt_order is unsigned, the expression -opt_order has a (large)
> >> positive value obtained by wrapping the mathematical negation of
> >> opt_order into the proper number of bits (32 here).  The type of the
> >> expression is still unsigned.  When an out of range value is assigned
> >> to a signed type, the result is undefined.  Most compilers seem to
> >
> > Wrong. Overflow in signed arithmetic would be undefined, but converting
> > a value to a signed integer type when the value cannot be represented in
> > that type is implementation-defined behavior. GCC defines that the value
> > is reduced modulo 2^N (N=width of the type). If GCC 4.1 behaves as
> > described that is a bug which goes against defined behavior.
> 
> Undefined or implementation-defined, it's a bad thing to be doing.

Not particularly bad I think - it's unlikely that a compiler would
define it differently on a machine with two's complement arithmetic, and
IIRC FFmpeg already relies on similar behavior at least for things like
shifts of signed variables.