speaking of NaN() and other entertainment...
i fought this battle with awk a few months ago. at ahron's suggestion,
i ported a current copy (as of november or so) of awk to plan 9. i just put
the port up on sources for hopeful submission. i've been running
this version of awk for 4 months with no problems found.
however, i found that the following script does very bad things to
the current distribution's awk. in fact, it was able to do bad things
to sun's various awkery and gnu awk as well. it exposes numbers that
are incorrectly converted but cause a delayed fpe. on unix, the fpe
is supressed due to the setting of the fcr.
; cat /tmp/testawk
BEGIN{
s = "01234567890";
printf "%x\n", 4215866817.
g = 1. # delayed fpe
printf "%08x", 4215866817.
print substr(s, 4215866817., 1)
s = substr(s, 1, 4215866817.)
g= 1. # delayed fpe
printf utf(4215866817.);
g= 1. # delayed fpe
}
if i run this from sources, you'll see that the delayed fpe causes
a bad value to float (ha) around for a bit (as an integer):
; /n/sources/plan9/386/bin/awk -f /n/sources/contrib/quanstro/testawk
80000000
/n/sources/plan9/386/bin/awk: floating point exception 6
/n/sources/plan9/386/bin/awk: floating point exception 6
/n/sources/plan9/386/bin/awk: floating point exception 6
/n/sources/plan9/386/bin/awk: floating point exception 6
/n/sources/plan9/386/bin/awk: floating point exception 6
/n/sources/plan9/386/bin/awk: floating point exception 6<DEL>
bwk's current code with a minor change to be really defensive
when converting to integer (contrib quanstro/awk) avoids
this problem (the Runeerror was convereted to u+fffd
to avoid mailer glitches):
; /n/sources/contrib/quanstro/root/386/bin/awk -f
/n/sources/contrib/quanstro/testawk
fb4905c1
fb4905c1
awk: utf argument out-of-range 4.21587e+09
source line 9
u+fffd;
- erik
