[Ffmpeg-cvslog] r8474 - trunk/libavcodec/resample2.c

[Uoti Urpala]

> > On Fri, 2007-03-23 at 01:14 +0100, Michael Niedermayer wrote:
> > > multiplication of signed numbers behaves the same on every 
> > > twos complement architecture which is identical to unsigned multiplication
> > > 
> > > its highly unintuitive if it breaks, though iam not arguing against that
> > > it may be undefined strictly speaking, shift right of signed numbers is
> > > too and i too would say gcc is broken if (-1)>>1 != -1 on a twos complement
> > > architecture because it is from a practical POV

On Fri, Mar 23, 2007 at 02:50:50AM +0200, Uoti Urpala wrote:
> > Right shift of positive signed numbers is defined by the standard. Right
> > shift of negative numbers is implementation-defined and gcc defines it
> > to work by sign extension in
> > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Integers-implementation.html
> > 
> > Overflow of signed number operations appears to be undefined rather than
> > implementation-defined. At least I didn't notice anything which would

On Thu, 2007-03-22 at 20:58 -0500, Rich Felker wrote:
> While you are correct, nothing about "undefined" precludes the
> implementation giving a definition. It just means that, unlike
> something specified to be "implementation defined", the implementation
> is not required to give a definition.

Of course an implementation can define more. There's still a difference
though. I got the impression that Michael might be implying "you need to
use undefined behavior or you can't even use right shifts with signed
numbers"; considering the standard signed overflow is on a less reliable
level than shifts.

> I agree quite strongly with Michael here that anything other than twos
> complement behavior with reduction modulo UINT_MAX (identical to the
> behavior for unsigned integers) is counterintuitive and idiotic,
> regardless of what the standard specifies. gcc has always historically
> behaved this way and I wonder why they changed it...

I think nobody on this list has really confirmed that it has been
intentionally changed. If it has, I'm pretty sure that it has not been
changed to some other numeric behavior but rather some optimizations
assume either that overflow will not occur or that results of
calculations which would overflow do not matter.