Skip Menu |
 

This queue is for tickets about the File-Slurp CPAN distribution.

Report information
The Basics
Id: 103986
Status: open
Priority: 0/
Queue: File-Slurp

People
Owner: Nobody in particular
Requestors: ROBINS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: JSON::PP is unable to decode JSON with newlines between tokens
Download (untitled) / with headers
text/plain 589b
The file pretty.json below does not parse, but compact.json parses. This is tested on both perl 5.18.2 and perl 5.20.2 on Ubuntu 14.04 (64-bit). The 5.18.2 perl version is system perl. 5.20.2 is perlbrewed with --thread --multi arguments. $ cat pretty.json { "a":"b", "c":1 } $ cat compact.json {"a":"b","c":1} $ perl -MFile::Slurp -MJSON::PP -E 'say decode_json read_file shift' compact.json HASH(0xa06d18) $ perl -MFile::Slurp -MJSON::PP -E 'say decode_json read_file shift' pretty.json , or } expected while parsing object/hash, at character offset 1 (before "\n") at -e line 1. $
Download (untitled) / with headers
text/plain 198b
It seems this is actually a bug with File::Slurp. $ perl -MIO::All -MJSON::PP -E 'say decode_json io->file(shift)->all' pretty.json HASH(0x10b2350) Can someone move it over to File::Slurp's queue?
Download (untitled) / with headers
text/plain 394b
Actually, adding in an explicit "scalar" before read_file solves the problem. The question is: Has JSON::PP's decode_json() ever had a prototype to enforce scalar context? Because if you have JSON::XS installed you don't need the "scalar". It seems it JSON::XS::decode_json has a prototype to enforce scalar context. This is confusing... Maybe it it is a bug belonging to JSON::PP after all...
Subject: Re: [rt.cpan.org #103986] JSON::PP is unable to decode JSON with newlines between tokens
Date: Sun, 26 Apr 2015 14:46:04 -0400
To: bug-File-Slurp [...] rt.cpan.org
From: Uri Guttman <uri [...] stemsystems.com>
Download (untitled) / with headers
text/plain 686b
On 04/26/2015 02:23 PM, Robin Smidsrød via RT wrote: Show quoted text
> Queue: File-Slurp > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=103986 > > > Actually, adding in an explicit "scalar" before read_file solves the problem. The question is: Has JSON::PP's decode_json() ever had a prototype to enforce scalar context? Because if you have JSON::XS installed you don't need the "scalar". It seems it JSON::XS::decode_json has a prototype to enforce scalar context. > > This is confusing... Maybe it it is a bug belonging to JSON::PP after all...
it is absolutely a bug in json::pp. read_file has a well defined and stable api with regard to scalar vs list context. thanx, uri
Download (untitled) / with headers
text/plain 522b
On 2015-04-26 14:23:57, ROBINS wrote: Show quoted text
> Actually, adding in an explicit "scalar" before read_file solves the > problem. The question is: Has JSON::PP's decode_json() ever had a > prototype to enforce scalar context? Because if you have JSON::XS > installed you don't need the "scalar". It seems it > JSON::XS::decode_json has a prototype to enforce scalar context.
See here: https://metacpan.org/source/MLEHMANN/JSON-XS-3.01/XS.xs#L2201 Show quoted text
> This is confusing... Maybe it it is a bug belonging to JSON::PP after > all...
Download (untitled) / with headers
text/plain 369b
The problem is with how the file is loaded from disk, in its handling of utf8-encoded characters. Basically, if there is any UTF-8 *anywhere* in the document, the entire file is decoded to characters and utf8-flagged, and that breaks uses of substr() in perl 5.8.6 and below. It is a mistake to try to infer the encoding of the document by inspecting its contents.
Download (untitled) / with headers
text/plain 599b
On 2015-05-21 23:37:41, ETHER wrote: Show quoted text
> The problem is with how the file is loaded from disk, in its handling > of utf8-encoded characters. > > Basically, if there is any UTF-8 *anywhere* in the document, the > entire file is decoded to characters and utf8-flagged, and that breaks > uses of substr() in perl 5.8.6 and below. > > It is a mistake to try to infer the encoding of the document by > inspecting its contents.
Sorry, this was a response to the wrong ticket (which has the same error result -- I was describing the issue that was fixed here -- https://github.com/makamaka/JSON-PP/pull/9)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.