[FFmpeg-devel] [PATCH] AAC: type puns for 16 bit floating point rounding
Fri Dec 5 04:34:41 CET 2008
On Fri, 2008-12-05 at 02:23 +0000, M?ns Rullg?rd wrote:
> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> > First you claimed that GCC just "happened to" generate a particular
> > result. That was false; GCC explicitly defines the behavior.
> >From a standards point of view there is no difference. Things are
> either in the standard or not. Behaviour under aliasing is
You're basically saying that it doesn't matter if you make false claims
because you think you're right in the end anyway.
> > 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;
> There may not be a compiler in existence right now that does it
> differently. That does not preclude a compiler with different
> behaviour being written tomorrow. Would you like me to write one for
The behavior in a seriously written compiler won't be random. A compiler
written with the intention to make it annoy people obviously doesn't
> > it's not an arbitrary thing that each compiler would be likely to
> > pick randomly.
> Yes, it is. That is the meaning of UNDEFINED in the standard.
Undefined means the standard makes _no_ requirements. It does not mean
the standard would prohibit compiler writers from using their brain and
instead require them to throw dice to make _every_ undefined behavior
> >> >> > (like right shifting negative numbers, or casting unsigned to
> >> >> > signed to get a negative result).
> > 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?
> Representation of numbers is implementation-defined. This implies
> that a compiler must make a choice and document it. Furthermore,
> using different representations would result in incompatible machine
> code. Changing the representation of numbers would require a change
> of the ABI for the machine/OS, and this does not happen unnoticed.
Neither shifting nor casting results are determined by representation.
> Things left UNDEFINED by the standard, on the other hand, are free to
> change arbitrarily between different compilers, versions of the same
> compiler, or depending on compiler flags. A change will not matter to
> conforming code. This is not just hypothetical. Compilers do vary,
> and gcc frequently changes the details of undefined aspects, often due
> to changes in the optimiser.
Again a strawman argument. Of course there are lots of undefined things
which are likely to change and have changed. But I have obviously never
claimed that _no_ undefined thing is unpredictable.
> Again, I ask you to name the other compilers you have verified the
> behaviour of. Did you check even one?
What does it matter if I give a compiler name? That alone would prove
> > 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?
> Ideally I would want all such code to be either rewritten properly or
> protected so as not to be compiled with unknown compilers.
Good luck with that...
> > 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.
> Your reply merely regurgitated your old arguments about gcc doing it
> this way or that and how it would be rude of someone to write a
> compiler behaving differently.
A blatant lie. Here's what I wrote:
Disallowing that would break even more code than the GCC introduction of
strict aliasing did, it's desirable to have some supported mechanism for
type punning, and disallowing it is unlikely to allow any significant
The only mention of GCC is referring to the amount of code that already
broke when GCC's level of aliasing requirements was introduced. None of
the arguments is specific to GCC.
I think your arguments are getting stupid enough that continuing the
thread further is a waste of time.
More information about the ffmpeg-devel