From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13861 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Damian McGuckin Newsgroups: gmane.linux.lib.musl.general Subject: Re: FE Exception triggered by comparison Date: Mon, 25 Feb 2019 08:50:52 +1100 (AEDT) Message-ID: References: <20190224192511.GZ21289@port70.net> <20190224210438.6980bd87@inria.fr> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="260386"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Alpine 2.02 (LRH 1266 2009-07-14) To: musl@lists.openwall.com Original-X-From: musl-return-13877-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 24 22:51:11 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gy1fz-0015dC-8W for gllmg-musl@m.gmane.org; Sun, 24 Feb 2019 22:51:11 +0100 Original-Received: (qmail 22342 invoked by uid 550); 24 Feb 2019 21:51:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22323 invoked from network); 24 Feb 2019 21:51:08 -0000 X-Authentication-Warning: key0.esi.com.au: damianm owned process doing -bs In-Reply-To: <20190224210438.6980bd87@inria.fr> Xref: news.gmane.org gmane.linux.lib.musl.general:13861 Archived-At: 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 http://754r.ucbtest.org/drafts/ 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. Thanks. > 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