Bleadperl v5.19.0-570-gb127e37 breaks PERLER/JavaScript-Dumper-0.011.tar.gz #13530
Comments
From @andkgit commit b127e37 PATCH: [perl #108378] [perl #115800] diagnostics http://www.cpantesters.org/cpan/report/d2dd3370-d826-11e2-bc6f-95dabcbf7481 Thanks to Slaven Rezić for finding this. perl -V Summary of my perl5 (revision 5 version 19 subversion 1) configuration: Characteristics of this binary (from libperl): -- |
From @khwilliamsonHere's the email we got for one ticket that would be nice to add to It occurs to me that these emails may be machine generated, and if so, -------- Original Message -------- # New Ticket Created by (Andreas J. Koenig) git commit b127e37 PATCH: [perl #108378] [perl #115800] diagnostics http://www.cpantesters.org/cpan/report/d2dd3370-d826-11e2-bc6f-95dabcbf7481 Thanks to Slaven Rezić for finding this. perl -V Summary of my perl5 (revision 5 version 19 subversion 1) configuration: config_args='-Dprefix=/home/sand/src/perl/repoperls/installed-perls/perl/v5.19.0-570-gb127e37/a2da Characteristics of this binary (from libperl): /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.0-570-gb127e37/a2da/lib/site_perl/5.19.1/x86_64-linux-thread-multi-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.0-570-gb127e37/a2da/lib/site_perl/5.19.1 /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.0-570-gb127e37/a2da/lib/5.19.1/x86_64-linux-thread-multi-ld /home/sand/src/perl/repoperls/installed-perls/perl/v5.19.0-570-gb127e37/a2da/lib/5.19.1 -- |
|
The RT System itself - Status changed from 'new' to 'open' |
From @khwilliamsonOn Wed Jan 15 22:56:35 2014, andreas.koenig.7os6VVqR@franz.ak.mind.de wrote:
The test that fails in 5.19 is expecting a floating point number to be returned by JSON to be enclosed in double quotes, which it used to be, but after the blamed commit, no longer is. I have tracked this down to the following statement in JSON::PP (JSON:XS has a similar logic): return $value # as is 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 -- |
From schmorp@schmorp.deOn Wed, Mar 05, 2014 at 11:09:47AM -0800, Karl Williamson via RT <perlbug-followup@perl.org> wrote:
Without seeing the test code nor the patch (both weren't easily Perl scalars are (for the most part) typeless - scalars are not NVs or PVs, JSON::XS (and JSON::PP, which copied the logic) attempts the impossible The short version is that the last use/modification counts, and the string
In your case, this is true, in other cases, this isn't. If you want to The the treatment of "types" varies considerably within perl versions, and
The test si simply there because in JSON, the number 5 is different than
The locale changes recently introduced in 5.19 cause a great deal of
The problem is that it's not clear what to do in that case. JSON::XS has to If the += 0 "trick" no longer works because perl stringifies the NV, then we However, such a change would break an enourmous number of programs (most -- |
From @khwilliamsonOn 3/5/2014 10:06 PM, Marc Lehmann wrote:
What if the code in JOSN::PP instead did something like this: if ($flags & ( B::SVp_IOK | B::SVp_NOK ) { # SvTYPE is IV or NV? Would that also work reliably? And insulate the code from us cretins on |
From @khwilliamsonI submitted a patch to the distribution so am resolving this core ticket |
|
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121013 (status was 'resolved')
Searchable as RT121013$
The text was updated successfully, but these errors were encountered: