On Wed Jan 15 22:56:35 2014, andreas.koenig.7os6vvqr@franz.ak.mind.de wrote:
git
---
commit b127e37e51c21b0a36755dcd19811be931a03d83
Author: Karl Williamson <public@khwilliamson.com>
Date: Mon May 13 07:35:35 2013 -0600
PATCH: [perl #108378] [perl #115800]
diagnostics
-----------
http://www.cpantesters.org/cpan/report/d2dd3370-d826-11e2-bc6f-
95dabcbf7481
Thanks to Slaven Rezić for finding this.
git
---
commit b127e37e51c21b0a36755dcd19811be931a03d83
Author: Karl Williamson <public@khwilliamson.com>
Date: Mon May 13 07:35:35 2013 -0600
PATCH: [perl #108378] [perl #115800]
diagnostics
-----------
http://www.cpantesters.org/cpan/report/d2dd3370-d826-11e2-bc6f-
95dabcbf7481
Thanks to Slaven Rezić for finding this.
return $value # as is
if $flags & ( B::SVp_IOK | B::SVp_NOK ) and !( $flags & B::SVp_POK ); # SvTYPE is IV or NV?
The blamed commit changed things so that some scalars that are NVs no longer are also PVs. In the past this statement would not return and code further down would enclose it in double quotes, hence the old behavior, and the new.
But the logic here seems wrong to me. I don't understand the possible nuances and gotchas, but it seems to me that if something is an NV, it should be returned as an NV, without regard to if there is a stringified version available or not, which is what SVp_POK indicates.
My guess is that the tests for POK are to detect cases where something has a numeric value, but its string is different from that value and needs to be preserved, such as perhaps "00" (I don't know the internals here, so am just guessing.) But there is no restriction on somebody's deciding to make a numeric scalar POK. It can be done for good reasons, and it could be done for invalid ones. The modules shouldn't depend on this.
(In this case, prior to the blamed commit, a floating point number was made POK when its string form was needed, in order to avoid having to recalculate it each time. But this was found to create bugs where the decimal point varies in a program between, say, a comma and a dot because of locale differences. Making it POK cemented the decimal point to what it was at the time it was first stringified, not what it should be the next time a stringified version is needed. So it isn't made POK and is recalculated each time)
I think that both JSON::PP and JSON::XS should add logic to better detect whether something's string is different from its numeric value
--
Karl Williamson
---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121013