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

Uoti Urpala uoti.urpala
Fri Dec 5 20:12:35 CET 2008

On Fri, 2008-12-05 at 10:46 +0000, M?ns Rullg?rd wrote:
> Uoti Urpala wrote:
> > 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.
> Try one more time to understand: if a feature is not part of the standard,
> it is not relevant for a portable programme whether or not some compiler
> implements said feature.  As long as a possibility exists for a standards-
> compliant compiler not to implement the feature, portable code cannot use
> it.

You keep making the same mistake again and again: grouping all behavior
left undefined by the standard in one equal group. Then you make
strawman arguments implying I want to rely on any undefined behavior
which happens one way one one compiler. The reality is that there's more
than strict black and white. Some things you can use reasonably safely
for reasons other than the standard, others are unsafe (some of them
despite being defined by the standard).

I'll refer to the above with (*) later in the post.

> The result of aliasing through pointers works *is* pretty much random.
> It depends entirely on whether the compiler performed a reordering
> optimisation or not.

What's this got to do with anything? The subject was not aliasing
through pointers but directly using the fields of a union.

[various other inaccurate stuff in the mail snipped]

> > 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
> > completely unpredictable.
> If the standard makes *no* requirements, as you seem to agree is the case,
> it also does not require compiler authors to agree on how to handle these
> situations, and it certainly does not require them to agree with you.

But there can be reasons other than the standard. (*) again.

> independently of representation, right-shifting of negative numbers is
> implementation-defined, not undefined.
> >> 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.
> So undefined behaviour should be treated as unpredictable, except when
> the current behaviour with one compiler happens to be convenient?

(*) again.

> >> > 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
> > optimizations.
> > ----
> Different words, same meaning.

Explaining why breaking the functionality would have significant
drawbacks and little benefit is "seeing gcc as the centre of the

> > I think your arguments are getting stupid enough that continuing the
> > thread further is a waste of time.
> I think you finally ran out of everything resembling an argument and thus
> had to take to insults.
> All your so-called arguments can be summarised as one of "gcc does it like
> that", "I like it that way", "all other compilers, none of which I bothered
> to check, do the same".  Please get some verifiable facts, or go away.

You posted this after replying to the mail from Dave Dodge about the C
standard clarification. Can you still not admit that I was right? What
exactly are you claiming now? You can't claim that I was wrong about the
feature being reasonably safe to use (unless you want to appear even
more ridiculous). So what are you arguing now? That I was right for the
wrong reasons, and it was by pure chance that my conclusion was correct?
That it was just unbelievable luck that the standard committee had later
defined exactly the case I was talking about? Are you going to start a
similar argument again the next time I say something can be reasonably
used despite not being in a standard?

More information about the ffmpeg-devel mailing list