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

[Måns Rullgård]

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

> 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).

Those "other reasons" must be mentioned in the compiler
documentation.  You did not provide a reference to such documentation
for any compiler other than gcc.

> 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.

I was discussing undefined behaviour in general.

>> > 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.

Yes, extension standards like SUS/POSIX can mandate specific choices
left undefined or implementation-defined by the C standard.  There
still needs to be a written statement somewhere.

>> 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.

There is a term for what you are doing now: wishful thinking.

>> >> > 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
> universe"?

Explaining why something would be inconvenient does not prove that it
does not exist.

>> > 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.

Yes, so what?  Situations with undefined behaviour are still
plentiful.

> Can you still not admit that I was right?

No.  When you started arguing YOU DID NOT KNOW the standard had been
amended.  Anything you said must be interpreted in the context of the
previous version of the standard, and in that version IT WAS NOT
SAFE.  Ergo you were WRONG.

Furthermore, the behaviour of any compiler released before the
publication of the amendment will have to be checked before it can be
relied upon.

> What exactly are you claiming now? You can't claim that I was wrong
> about the feature being reasonably safe to use.

You were wrong about the feature being safe under the previous version
of the standard.

> 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?

Something like that.

> That it was just unbelievable luck that the standard committee had
> later defined exactly the case I was talking about?

Your arguments for making this type of punning well-defined were
sound.  Apparently the standards committee came to similar
conclusions.  I wouldn't call it "unbelievable luck", although this
outcome was by no means inevitable.

> 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?

Probably.

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