Front page | perl.perl5.porters |
Postings from July 2010
On Wed, 28 Jul 2010, Nicholas Clark wrote: > And if you're really up for it, there's a bug with no obvious fix if your > system supports negative zero: > > $ perl -wle '$a = 0/-1; print $a ? "T" : "F"; print $a; print $a ? "T" : "F";' > F > -0 > T > > > the problem being that the implementation of true/false is > > is there a string value? > Y: is it "0" or ""? > is there a numeric value? > Y: is it == 0 > ... > > > IEEE floating point has -0 numerically equal to 0, so that makes it false. > But if you then cause that value to be used as a string (such as that print) > then the string representation is cached, and it doesn't meet the value of > falsehood. > > This *is* inconsistent with the documentation, and with the general intended > behaviour, but I can't see a way to fix it. Whereas the behaviour of strings > such as "0e0" and "00" and "0.0" is consistent with both the intent and the > documentation. Well, you _could_ add a special case to the string comparison: is there a string value which is "-0" and a numeric value? Y: is the numeric value == 0 is there a string value? Y: is it "0" or ""? is there a numeric value? Y: is it == 0 ... This would preserve the boolean value of -0 across stringification, at a minimal runtime costs for all boolean value checks. I have no opinion right now if we _should_ do this though. Cheers, -JanThread Previous | Thread Next