Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Feb 2019 08:50:52 +1100 (AEDT)
From: Damian McGuckin <>
Subject: Re: FE Exception triggered by comparison

Hi Markus, Jens,

Thanks for the replies.

On Sun, 24 Feb 2019, Jens Gustedt wrote:

>> with c99 annex F, c == and != operators are mapped to ieee 754
>> compareQuiet{Not}Equal, which is non-signaling with qNaN inputs
>> but signals invalid with sNaN inputs, so in practice sNaN != sNaN
>> will signal in c.

I guess I am still trying to figure out where/when sNaN will appear so I 
can code defensively to protect my code. The C interface like 'isless' and 
friends are really woeful performers.

>> i think it's better to look at the ieee 754 spec instead
>> of the c spec, drafts are at

I agree. But while I found the 1985 standard readable and clear, all the 
subsequent revisions have sections, especially related to exceptions, that 
are difficult to comprehend. And I thought I spoke English. The language 
is convoluted.

> Yes, we are currently integrating parts 1 and 2 of this TS into the
> standard. Usually you should be able to see a first version of that in
> a few weeks in the pre-London mailing.


> For the moment they are integrated "as such" that is with "WANT"
> macros that make these "new" interfaces optional.

Hmmm. Scary. I

The context of this is that I want a coding style which means I can 
compare numbers without affecting the exception state. And it must have 
zero overhead, and not affect the readability of the code, i.e. no 
function calls.

I want to know that

 	x != x

will always detect any NaN with affecting the exception status and that
comparisons like

 	if (x == x) { ... }
 	else if (x > y) { .... }
 	else if (x < y) { .... }
 	else { x or y are NaN }

will similarly also not modify the exception status, and in the last 
section let me process how I interpret the NaNs.

Otherwise, avoidance of creating spurious exceptions forces you to start 
working at the IEEE 754 encoding level. This is counterproductive to clear 
and concise programming. Such a style is riddled through a lot of the 
maths routines in MUSL and the libraries that came before it. It also 
means that all these magic constants start to appear in the code, severely 
affecting comprehensibility. Any generic coding style is just stopped in 
its tracks.

Regards - Damian

Pacific Engineering Systems International, 277-279 Broadway, Glebe NSW 2037
Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
Views & opinions here are mine and not those of any past or present employer

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.