From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <edc4b3708504ed165efca91446d0f903@felloff.net>
Date: Sat, 30 Apr 2016 14:40:54 +0200
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: [9fans] store NaN() to memory traps on 386 (387)
Topicbox-Message-UUID: 8e0692b0-ead9-11e9-9d60-3106f5b1d025

with spews recent native awk port, we'v discovered an issue
with strtod() that with the default FCR; which has FPINVALs
traps enabled; the FMOVDP instruction that stores a NaN to memory
traps. so it is not really possible to check for NaN result of
strtod() unless you mask the traps.

The APE port of awk got away with strtod() not recognizing
"nan" at all, while the native plan9 libc version does.

so the problem is that NaN() appears to be unusable with the
default FCR on 387, and we'd like to have consistent behaviour
under all archs when possible.

right now, the 387 seems to be the single oddball, so one idea
was to have NaN() return a quiet NaN for 387 only instead of a
signaling one.

On the other hand, one could argue that programs relying on
NaN's have to explicitely disable FPINVAL traps on all archs.

Any suggestions on how to resolve this?

--
cinap