Mark Kettenis <mark.kette...@xs4all.nl> writes: >> From: j...@wxcvbn.org (=?utf-8?Q?J=C3=A9r=C3=A9mie_Courr=C3=A8ges-Anglas?=) >> Date: Sun, 14 Jul 2013 09:41:28 +0200 >> >> >> This diff updates awk to the 20121220 upstream version, with a few >> fixups. >> >> ok? >> >> Index: tran.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/awk/tran.c,v >> retrieving revision 1.15 >> diff -u -p -r1.15 tran.c >> --- tran.c 28 Sep 2011 19:27:18 -0000 1.15 >> +++ tran.c 22 Jun 2013 21:47:01 -0000 >> @@ -299,6 +299,8 @@ Awkfloat setfval(Cell *vp, Awkfloat f) / >> xfree(vp->sval); /* free any previous string */ >> vp->tval &= ~STR; /* mark string invalid */ >> vp->tval |= NUM; /* mark number ok */ >> + if (f == -0) /* who would have thought this possible? */ >> + f = 0; > > This is a bit silly. Even though floating point values may be able to > repesent signed zeroes (the IEEE standard formats do) they are > guaranteed to compare equal to the zero with the opposite sign. > > This diff forces all zeroes to be positive zeroes. Not sure that is > desirable.
When I looked at this, I thought the same. Then I thought I was being paranoid, and thought "why not?". That's probably not the right way to handle this indeed. I've just mailed upstream, maybe there is a reason I fail to see for this change. Let's see if this leads to failures in the bulk build currently running. > GNU awk seems to treat them differently. See > > > <http://www.gnu.org/software/gawk/manual/html_node/Unexpected-Results.html#Unexpected-Results> Yup. > Cheers, > > Mark Regards, -- Jérémie Courrèges-Anglas PGP Key fingerprint: 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494
