not-a-number's

[Mischa Baars]

On 01/16/2013 01:28 PM, Robert Dewar wrote:
> On 1/16/2013 7:10 AM, Mischa Baars wrote:
>
>> And as I have said before: if you are satisfied with the answer '2',
>> then so be it and you keep the compiler the way it is, personally I'm am
>> not able to accept changes to the sources anyway. I don't think it is
>> the right answer though.
>
> The fact that you don't think that gcc shoudl follow the C standard
> is hardly convincing unless it is backed up by convincing technical
> argument. I see nothing surprising about the 2 here, indeed any other
> answer *would* be surprising. I still don't understand the basis for
> your non-stnadard views.
>>
>> Mischa.
>>
>

Let me explain again for you. Every 'if' statement in C is translated 
into a 'fucom' or similar instruction, which sets a number of conditions 
flags in the co-processor. Some instructions need you to load these into 
the eflags register manually, others don't.

Now, as soon as the 'fucom' or similar instruction encounters a 
'signalling not-a-number' or 'quiet not-a-number' as one or both of it's 
arguments, the condition code is set to 'not comparable'. This has 
nothing to do with the C specification, but purely with the Intel/AMD 
hardware.

If you ask me, it would be counter-intuitive to change the value of the 
condition code to some other value and call that the new standard. 
Instead it would seem logical to use the 'not comparable' and terminate 
the 'if' statement.

Does that make sense to you?

In our example, a 'not-a-number' would be returned to the main program, 
without the need for an extra 'isnan()'.

Mischa.