> to cinap's point, either nan -> float doesn't trap, and there is no protection
> against bad fp math, or it does trap, and one has protection against producing
> inadvertant nans.
> by the way, the same issue exists with sse.
with SSE, i can assign SNaN's to variables and test for them with isN
On Mon May 2 12:30:03 PDT 2016, rym...@gmail.com wrote:
> Not crash into a flaming ball of (very vague) fire?
the obvious loop with nan
for(i in `{seq nan >[2=]}){echo $i}
prints nothing, as the body is never executed.
what would you have it do?
to cinap's point, either nan -> float
>> cpu% seq nan
>> seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081
>> pc=0x122
> that seems reasonable to me. what could seq possibly do with nan?
thats the thing. its not expecting nan. and having the process trap
for this input seems rather drastic. imagine we'
Not crash into a flaming ball of (very vague) fire?
On Mon, May 2, 2016 at 2:17 PM, erik quanstrom
wrote:
> On Mon May 2 12:07:58 PDT 2016, cinap_len...@felloff.net wrote:
> >
> > > file under: awk was really designed for pre-posix unix. :-)
> >
> > its not just about awk. whenever you want to
On Mon May 2 12:07:58 PDT 2016, cinap_len...@felloff.net wrote:
>
> > file under: awk was really designed for pre-posix unix. :-)
>
> its not just about awk. whenever you want to convert a string to
> a floating point number under plan9 you'll have to deal with this
> problem:
>
> cpu% seq nan
> file under: awk was really designed for pre-posix unix. :-)
its not just about awk. whenever you want to convert a string to
a floating point number under plan9 you'll have to deal with this
problem:
cpu% seq nan
seq 11791387: suicide: sys: fp: invalid operation fppc=0x2635 status=0x8081
pc=
> what sucks is that passing "nan" to strtod() will result in a program
> crash with the default fcr instead of rejecting the string. so everyone
> is forced to filter the inputs to strtod() to avoid the crash, or change
> the fcr and then deal with the nan's and infs.
file under: awk was really d
my initial analysis was wrong. i got fooled by the asynchronous nature
of the exception delivery. the trap already happend on the FLD instruction
when we try to load the SNaN from memory.
what sucks is that passing "nan" to strtod() will result in a program
crash with the default fcr instead of re
On Sat Apr 30 05:53:04 PDT 2016, cinap_len...@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 c
following up, theres another idea:
given that what we want is fp-arithmetic on NaN's to trap when FPINVAL
is set in the fcr, but not when doing simple assignments, what if we just
deal with it in the kernels exception handler for 387?
so when the store traps, and source operand is a SNaN, we just
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
11 matches
Mail list logo