[FFmpeg-devel] [PATCH] AAC: type puns for 16 bit floating point rounding

Uoti Urpala uoti.urpala
Fri Dec 5 02:37:21 CET 2008

On Fri, 2008-12-05 at 00:16 +0000, M?ns Rullg?rd wrote:
> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> > On Thu, 2008-12-04 at 17:11 +0000, M?ns Rullg?rd wrote:
> >> Uoti Urpala wrote:
> >> > On Thu, 2008-12-04 at 14:22 +0000, M?ns Rullg?rd wrote:
> >> >> That is only true in the reverse situation, i.e. when the standard allows
> >> >> something but gcc misbehaves.  Then we have no choice but avoiding the
> >> >> offending construct.  If gcc happens to generate intuitively correct
> >> >> code for something that is undefined by the standard, we should still not
> >> >> be using that something.
> >> >
> >> > It's not that GCC "happens to" generate the correct result, but that it
> >> > explicitly defines it will work.
> >> 
> >> Same thing.  GCC happens to define this one way.  Another compiler may do
> >> it differently.  GCC is not the only compiler.
> >
> > It's not the same thing. There are things undefined by the standard
> > which GCC currently happens to implement one way but which are "random"
> > and shouldn't be trusted to stay that way or to work the same on other
> > compilers. This case is not one of those.
> You fail to see the point.  Assuming conforming compilers, all that
> matters is the standard.  If specific compilers define specific
> behaviour outside the scope of the standard, this behaviour should not
> be relied upon, except when the code will never be compiled with
> another compiler, e.g. gcc-style inline assembler.

You've never had a point. First you claimed that GCC just "happened to"
generate a particular result. That was false; GCC explicitly defines the
behavior. Then you changed the claim to "GCC defines it this way, but
another compiler may just as well do it another way". That was false
too; it's not an arbitrary thing that each compiler would be likely to
pick randomly. Now you're making a strawman argument, implying that my
opinion would be based on GCC behavior only (saying that "specific
compilers define specific behavior" is not enough to do something).
That's also invalid; my opinion has never been based on GCC behavior

> >> >> There is no telling what another compiler or a future version of
> >> >> gcc might do.
> >> >
> >> > You can tell with reasonable certainty. GCC has explicitly defined that
> >> > it will work. If you don't rely on that then you shouldn't rely on other
> >> > compiler-defined behavior either
> >> 
> >> I endeavour not to.
> >> 
> >> > (like right shifting negative numbers, or casting unsigned to
> >> > signed to get a negative result).
> >> 
> >> As I said before, that excludes some Cray systems.
> >
> > What does that have to do with hardware?
> Where did I say anything about hardware.  For the purposes of this
> discussion, the "system" includes the compiler and C library.

Then why do you believe *that* compiler-defined behavior can never
change, and why is code relying on it not subject to your requirements
that you stated without any exceptions for practical cases?

> > A compiler is free to define those any way it wants on any hardware.
> > And defining right shifting to produce the same result as first
> > casting to unsigned and then shifting is likely as good a match for
> > hardware as sign extension.
> It is an assumed, and a reasonably so these days, in FFmpeg that
> integers use two's complement representation, and that right shift of
> a signed integer replicates the sign bit.  We also know these
> assumptions to be true for all hardware/compiler variants we wish to
> support.  Furthermore, the C99 standard specifies representation of
> and operations on signed integers to be implementation-defined,
> meaning that a compiler should behave in a consistent, documented
> manner.
> The effects of violating the aliasing rules are *undefined*.
> Implementations are not required to document their behaviour, nor need
> the behaviour be consistent.

The C standard itself does not require that. However, because of how
common such issues are in programs, the compiler writers do need to
consider how to approach the issue and do need to make a consistent

> > Also practically all floating point in FFmpeg relies on sane compiler
> > behavior rather than any standard (FFmpeg assumes much more than is
> > guaranteed by the C standard, but does not request standard IEEE
> > behavior either and is not compiled according to that on x86 with any
> > compiler I know of).
> >
> >> >> If there is any chance at all that it might fail, it should not be done.
> >> >
> >> > Then you'll get nothing done.
> >> 
> >> There will of course always be mistakes, and we can never be sure we've
> >> corrected them all.  However, we can make a good effort to avoid things
> >> we *know* to be undefined.
> >
> > "Undefined by a particular standard" is not the _only_ measure.
> Being defined by a relevant standard is a necessary, but not
> sufficient, condition for something to be safely used.  Other
> conditions include correct compiler support.

As illustrated by the examples above there's lots of code in FFmpeg that
is not defined by a standard. Do you want to have all of it removed?

I don't know what your definition of the term "safely used" is, but it
is not necessary for everything to be defined by a standard. There
should be *some* reason to believe that a piece of code works and will
continue to work. That its behavior follows from the requirements of a
standard is a common reason and often an easily verifiable one, but it's
not the only possible one. Practically all programs have some parts not
covered by standards; that doesn't mean they would be unreliable or hard
to port.

> > This case can be expected to work for other reasons
> Such as?

You already asked why I thought a compiler would be unlikely to use more
strict rules. I replied, and then in response you wrote only nonsense
about "seeing gcc as the centre of the universe" even though my reply
was in no way specific to GCC. Now you're asking basically the same
thing again?

More information about the ffmpeg-devel mailing list