Front page | perl.perl5.porters |
Postings from July 2010
On Wed, 28 Jul 2010, Jan Dubois wrote: > 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. That rule will fail in the opposite direction: $ perl -e '$a = "-0"; print $a ? "T" : "F"; $_=$a+1.23; print $a ? "T" : "F";' It prints "TT" now but would print "TF" under the new rule. There is no way to distinguish if the SV started out as an NV and added the PV later, or if it was the other way round. So I don't see a way to fix it either, after all. Cheers, -JanThread Previous | Thread Next