Re: [9fans] store NaN() to memory traps on 386 (387)

[erik quanstrom <quanstro@quanstro.net>]

On Sat Apr 30 05:53:04 PDT 2016, cinap_lenrek@felloff.net wrote:
> 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?

i'll assume the context here is on initial conversion from input to fields.
vaguely the rule is anything that's properly representable as a number, is a number,
and anything else is a string.  since awk is well older than ieee, nan, inf,
one could easily argue they should count as strings.

so in my mind, this isn't an issue.  my solution would be if the string is nan,
then don't bother calling strtod.

the gawk maintainers while complaining about posix 2004, evidently agree,
providing --posix to disable filtering out nan and other strings from being
passed to strtod.

- erik