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

Måns Rullgård mans
Sun Jan 10 17:46:48 CET 2010


Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:

> 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

The spec allows for an "implementation-defined signal" to be raised
too.  That would be very bad.  I've seen enough breakage from signed
integer conversion to know not to rely on them, ever.

> IIRC FFmpeg already relies on similar behavior at least for things like
> shifts of signed variables.

That behaviour seems to be much more consistent across compilers than
things relating to signed overflow through arithmetic or conversions.

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



More information about the ffmpeg-cvslog mailing list