@@ -4,6 +4,13 @@ TODO: maybe detect and croak on more invalid inputs (e.g. +-inf/nan)
TODO: maybe avoid the reblessing and better support readonly objects.
TODO: http://stevehanov.ca/blog/index.php?id=104 compression
+3.0106 2014-11-11 (rurban)
+ - more minor doc improvements #26 (schwern)
+
+3.0105 2014-11-05 (rurban)
+ - minor doc improvements #25 (ether)
+ - fix d_Gconvert test in t/11_pc_expo.t for 5.6
+
3.0104 2014-04-26 (rurban)
- add t/z_leaktrace.t
- restore build on C89 (bulk88)
@@ -46,4 +46,3 @@ t/z_pod.t
typemap
META.yml Module YAML meta-data (added by MakeMaker)
META.json Module JSON meta-data (added by MakeMaker)
-SIGNATURE Public-key signature (added by MakeMaker)
@@ -4,7 +4,7 @@
"cPanel Inc. <cpan@cpanel.net>"
],
"dynamic_config" : 1,
- "generated_by" : "ExtUtils::MakeMaker version 6.88, CPAN::Meta::Converter version 2.132140",
+ "generated_by" : "ExtUtils::MakeMaker version 7, CPAN::Meta::Converter version 2.142690",
"license" : [
"perl_5"
],
@@ -54,5 +54,5 @@
"url" : "https://github.com/rurban/Cpanel-JSON-XS"
}
},
- "version" : "3.0104"
+ "version" : "3.0106"
}
@@ -3,29 +3,29 @@ abstract: 'JSON::XS for Cpanel, fast and correct serialising, also for 5.6.2'
author:
- 'cPanel Inc. <cpan@cpanel.net>'
build_requires:
- ExtUtils::MakeMaker: 0
+ ExtUtils::MakeMaker: '0'
configure_requires:
- ExtUtils::MakeMaker: 0
+ ExtUtils::MakeMaker: '0'
dynamic_config: 1
-generated_by: 'ExtUtils::MakeMaker version 6.88, CPAN::Meta::Converter version 2.132140'
+generated_by: 'ExtUtils::MakeMaker version 7, CPAN::Meta::Converter version 2.142690'
license: perl
meta-spec:
url: http://module-build.sourceforge.net/META-spec-v1.4.html
- version: 1.4
+ version: '1.4'
name: Cpanel-JSON-XS
no_index:
directory:
- t
- inc
recommends:
- Encode: 1.9801
- common::sense: 3.5
+ Encode: '1.9801'
+ common::sense: '3.5'
requires:
- Pod::Text: 2.08
- Pod::Usage: 1.33
+ Pod::Text: '2.08'
+ Pod::Usage: '1.33'
resources:
bugtracker: https://github.com/rurban/Cpanel-JSON-XS/issues
homepage: http://software.schmorp.de/pkg/JSON-XS.html
license: http://dev.perl.org/licenses/
repository: https://github.com/rurban/Cpanel-JSON-XS
-version: 3.0104
+version: '3.0106'
@@ -37,7 +37,7 @@ WriteMakefile(
},
}
) : ()),
- SIGN => 1,
+ #SIGN => 1,
);
package MY;
@@ -147,10 +147,10 @@ FUNCTIONAL INTERFACE
Except being faster.
$is_boolean = Cpanel::JSON::XS::is_bool $scalar
- Returns true if the passed scalar represents either
- Cpanel::JSON::XS::true or Cpanel::JSON::XS::false, two constants
- that act like 1 and 0, respectively and are used to represent JSON
- "true" and "false" values in Perl.
+ Returns true if the passed scalar represents either "JSON::XS::true"
+ or "JSON::XS::false", two constants that act like 1 and 0,
+ respectively and are used to represent JSON "true" and "false"
+ values in Perl.
See MAPPING, below, for more information on how JSON values are
mapped to Perl.
@@ -210,11 +210,11 @@ OBJECT-ORIENTED INTERFACE
If $enable is true (or missing), then the "encode" method will not
generate characters outside the code range 0..127 (which is ASCII).
Any Unicode characters outside that range will be escaped using
- either a single \uXXXX (BMP characters) or a double \uHHHH\uLLLLL
- escape sequence, as per RFC4627. The resulting encoded JSON text can
- be treated as a native Unicode string, an ascii-encoded,
- latin1-encoded or UTF-8 encoded string, or any other superset of
- ASCII.
+ either a single "\uXXXX" (BMP characters) or a double
+ "\uHHHH\uLLLLL" escape sequence, as per RFC4627. The resulting
+ encoded JSON text can be treated as a native Unicode string, an
+ ascii-encoded, latin1-encoded or UTF-8 encoded string, or any other
+ superset of ASCII.
If $enable is false, then the "encode" method will not escape
Unicode characters unless required by the JSON syntax or other
@@ -1004,14 +1004,15 @@ MAPPING
Note that precision is not accuracy - binary floating point values
cannot represent most decimal fractions exactly, and when converting
- from and to floating point, Cpanel::JSON::XS only guarantees
+ from and to floating point, "Cpanel::JSON::XS" only guarantees
precision up to but not including the least significant bit.
true, false
- These JSON atoms become "JSON::XS::true" and "JSON::XS::false",
- respectively. They are overloaded to act almost exactly like the
- numbers 1 and 0. You can check whether a scalar is a JSON boolean by
- using the "Cpanel::JSON::XS::is_bool" function.
+ These JSON atoms become "Cpanel::JSON::XS::true" and
+ "Cpanel::JSON::XS::false", respectively. They are overloaded to act
+ almost exactly like the numbers 1 and 0. You can check whether a
+ scalar is a JSON boolean by using the "Cpanel::JSON::XS::is_bool"
+ function.
null
A JSON null atom becomes "undef" in Perl.
@@ -1054,8 +1055,8 @@ MAPPING
Other unblessed references are generally not allowed and will cause
an exception to be thrown, except for references to the integers 0
and 1, which get turned into "false" and "true" atoms in JSON. You
- can also use "JSON::XS::false" and "JSON::XS::true" to improve
- readability.
+ can also use "Cpanel::JSON::XS::false" and "Cpanel::JSON::XS::true"
+ to improve readability.
encode_json [\0, Cpanel::JSON::XS::true] # yields [false,true]
@@ -1123,12 +1124,12 @@ MAPPING
syntax, tagged values.
SERIALISATION
- What happens when "JSON::XS" encounters a Perl object depends on the
- "allow_blessed", "convert_blessed" and "allow_tags" settings, which are
- used in this order:
+ What happens when "Cpanel::JSON::XS" encounters a Perl object depends on
+ the "allow_blessed", "convert_blessed" and "allow_tags" settings, which
+ are used in this order:
1. "allow_tags" is enabled and the object has a "FREEZE" method.
- In this case, "JSON::XS" uses the Types::Serialiser object
+ In this case, "Cpanel::JSON::XS" uses the Types::Serialiser object
serialisation protocol to create a tagged JSON value, using a
nonstandard extension to the JSON syntax.
@@ -1177,7 +1178,7 @@ MAPPING
4. none of the above
If none of the settings are enabled or the respective methods are
- missing, "JSON::XS" throws an exception.
+ missing, "Cpanel::JSON::XS" throws an exception.
DESERIALISATION
For deserialisation there are only two cases to consider: either
@@ -1192,10 +1193,10 @@ MAPPING
parse error will result (as if tagged values were not part of the
grammar).
- If "allow_tags" is enabled, "JSON::XS" will look up the "THAW" method of
- the package/classname used during serialisation (it will not attempt to
- load the package as a Perl module). If there is no such method, the
- decoding will fail with an error.
+ If "allow_tags" is enabled, "Cpanel::JSON::XS" will look up the "THAW"
+ method of the package/classname used during serialisation (it will not
+ attempt to load the package as a Perl module). If there is no such
+ method, the decoding will fail with an error.
Otherwise, the "THAW" method is invoked with the classname as first
argument, the constant string "JSON" as second argument, and all the
@@ -1377,57 +1378,16 @@ ENCODING/CODESET FLAG NOTES
If you know of other incompatibilities, please let me know.
JSON and YAML
- You often hear that JSON is a subset of YAML. This is, however, a mass
- hysteria(*) and very far from the truth (as of the time of this
- writing), so let me state it clearly: *in general, there is no way to
- configure JSON::XS to output a data structure as valid YAML* that works
- in all cases.
-
- If you really must use Cpanel::JSON::XS to generate YAML, you should use
- this algorithm (subject to change in future versions):
+ You often hear that JSON is a subset of YAML. *in general, there is no
+ way to configure JSON::XS to output a data structure as valid YAML* that
+ works in all cases. If you really must use Cpanel::JSON::XS to generate
+ YAML, you should use this algorithm (subject to change in future
+ versions):
my $to_yaml = Cpanel::JSON::XS->new->utf8->space_after (1);
my $yaml = $to_yaml->encode ($ref) . "\n";
This will *usually* generate JSON texts that also parse as valid YAML.
- Please note that YAML has hardcoded limits on (simple) object key
- lengths that JSON doesn't have and also has different and incompatible
- unicode character escape syntax, so you should make sure that your hash
- keys are noticeably shorter than the 1024 "stream characters" YAML
- allows and that you do not have characters with codepoint values outside
- the Unicode BMP (basic multilingual page). YAML also does not allow "\/"
- sequences in strings (which Cpanel::JSON::XS does not *currently*
- generate, but other JSON generators might).
-
- There might be other incompatibilities that I am not aware of (or the
- YAML specification has been changed yet again - it does so quite often).
- In general you should not try to generate YAML with a JSON generator or
- vice versa, or try to parse JSON with a YAML parser or vice versa:
- chances are high that you will run into severe interoperability problems
- when you least expect it.
-
- (*) I have been pressured multiple times by Brian Ingerson (one of the
- authors of the YAML specification) to remove this paragraph, despite
- him acknowledging that the actual incompatibilities exist. As I was
- personally bitten by this "JSON is YAML" lie, I refused and said I
- will continue to educate people about these issues, so others do not
- run into the same problem again and again. After this, Brian called
- me a (quote)*complete and worthless idiot*(unquote).
-
- In my opinion, instead of pressuring and insulting people who
- actually clarify issues with YAML and the wrong statements of some
- of its proponents, I would kindly suggest reading the JSON spec
- (which is not that difficult or long) and finally make YAML
- compatible to it, and educating users about the changes, instead of
- spreading lies about the real compatibility for many *years* and
- trying to silence people who point out that it isn't true.
-
- Addendum/2009: the YAML 1.2 spec is still incompatible with JSON,
- even though the incompatibilities have been documented (and are
- known to Brian) for many years and the spec makes explicit claims
- that YAML is a superset of JSON. It would be so easy to fix, but
- apparently, bullying people and corrupting userdata is so much
- easier.
SPEED
It seems that JSON::XS is surprisingly fast, as shown in the following
@@ -1516,8 +1476,7 @@ SECURITY CONSIDERATIONS
hostile creatures requires relatively few measures.
First of all, your JSON decoder should be secure, that is, should not
- have any buffer overflows. Obviously, this module should ensure that and
- I am trying hard on making that true, but you never know.
+ have any buffer overflows. Obviously, this module should ensure that.
Second, you need to avoid resource-starving attacks. That means you
should limit the size of JSON texts you accept, or make sure then when
@@ -1529,8 +1488,8 @@ SECURITY CONSIDERATIONS
in memory, so you might want to check the size before you accept the
string.
- Third, JSON::XS recurses using the C stack when decoding objects and
- arrays. The C stack is a limited resource: for instance, on my amd64
+ Third, Cpanel::JSON::XS recurses using the C stack when decoding objects
+ and arrays. The C stack is a limited resource: for instance, on my amd64
machine with 8MB of stack size I can decode around 180k nested arrays
but only 14k nested JSON objects (due to perl itself recursing deeply on
croak to free the temporary). If that is exceeded, the program crashes.
@@ -1538,16 +1497,13 @@ SECURITY CONSIDERATIONS
process has a smaller stack, you should adjust this setting accordingly
with the "max_depth" method.
- Something else could bomb you, too, that I forgot to think of. In that
- case, you get to keep the pieces. I am always open for hints, though...
-
- Also keep in mind that JSON::XS might leak contents of your Perl data
- structures in its error messages, so when you serialise sensitive
+ Also keep in mind that Cpanel::JSON::XS might leak contents of your Perl
+ data structures in its error messages, so when you serialise sensitive
information you might want to make sure that exceptions thrown by
JSON::XS will not end up in front of untrusted eyes.
- If you are using JSON::XS to return packets to consumption by JavaScript
- scripts in a browser you should have a look at
+ If you are using Cpanel::JSON::XS to return packets to consumption by
+ JavaScript scripts in a browser you should have a look at
<http://blog.archive.jpsykes.com/47/practical-csrf-and-json-security/>
to see whether you are vulnerable to some common attack vectors (which
really are browser design bugs, but it is still you who will have to
@@ -1556,10 +1512,10 @@ SECURITY CONSIDERATIONS
THREADS
Cpanel::JSON::XS has experimental ithreads support, unlike JSON::XS. If
- you encouter any bugs with thread support please report them.
+ you encounter any bugs with thread support please report them.
BUGS
- While the goal of the JSON::XS module is to be correct, that
+ While the goal of the Cpanel::JSON::XS module is to be correct, that
unfortunately does not mean it's bug-free, only that the author thinks
its design is bug-free. If you keep reporting bugs they will be fixed
swiftly, though.
@@ -1,71 +0,0 @@
-This file contains message digests of all files listed in MANIFEST,
-signed via the Module::Signature module, version 0.73.
-
-To verify the content in this distribution, first make sure you have
-Module::Signature installed, then type:
-
- % cpansign -v
-
-It will check each file's integrity, as well as the signature's
-validity. If "==> Signature verified OK! <==" is not displayed,
-the distribution may already have been compromised, and you should
-not run its Makefile.PL or Build.PL.
-
------BEGIN PGP SIGNED MESSAGE-----
-Hash: SHA1
-
-SHA1 9a56f3b919dfc8fced3803e165a2e38de62646e5 COPYING
-SHA1 54eef0889a59adbac82ab8700b423726d9dd2663 Changes
-SHA1 254f46232c5f7d22ea544a038ae8e752f7e7478c MANIFEST
-SHA1 9898158c93047646c6b4730da87d1072596984c4 META.json
-SHA1 30a564d8f47e4c0349383483e11f1cc60df8be46 META.yml
-SHA1 4856ef5cb39bd758f96d2bc3366c299ae80d383e Makefile.PL
-SHA1 34eaecbd45044afb4f19251f0832de090a557aad README
-SHA1 bd760c6b8ccf214f31e4d1ac618ec3ffadc5f383 XS.pm
-SHA1 e1faade8074b7c292bbd69cdccb414500c24e74a XS.xs
-SHA1 27b0bc7e0cd6fe90876fb3d285065c6a07cca028 XS/Boolean.pm
-SHA1 8fb15e5f4758020b1f5c449f39e2e4015f22ed19 bin/cpanel_json_xs
-SHA1 ea72bbe602baaabdd0004ef1d7e7cc3334b42bb4 eg/bench
-SHA1 d169c475eede0a30a9935619fec7352deeabc8d5 ppport.h
-SHA1 f7101031fd3fde35fe2421a07ab6cee8a822c00c t/00_load.t
-SHA1 6d767c3b922bc8ffb3f5f3127064c3978b1bcb9b t/01_utf8.t
-SHA1 4cd451633e448bab3104d9720e077b184632d9c6 t/02_error.t
-SHA1 300f2e4285edd3259eabe25e8bfd0289fa3543b0 t/03_types.t
-SHA1 d876bdffc381f4f67ec90f9c331e3ec2138946e2 t/04_dwiw_encode.t
-SHA1 94b1130a9b760102e0a24ad518f1e7439ef9122c t/05_dwiw_decode.t
-SHA1 d8c75d0fc7061469eba29275eb366b593c156f7d t/06_pc_pretty.t
-SHA1 f184df03869dc2baba2daa8d5c436c3996601607 t/07_pc_esc.t
-SHA1 18dc9908153d71debc18afd777983819f5ecce9a t/08_pc_base.t
-SHA1 94b5a3460023550b79b1d325016c951d9cb99fa1 t/09_pc_extra_number.t
-SHA1 849b88cb5f17ca6c2324c78e1c4cb1d7857caccb t/10_pc_keysort.t
-SHA1 770f86d8983d7e82da08b57c0aa0fc6a400588a9 t/11_pc_expo.t
-SHA1 9de3f095ceb9fb3614d54007e97c6c4afcfc962d t/12_blessed.t
-SHA1 4d553fd6b5e4486f087babff2946e0cb4b2c38fb t/13_limit.t
-SHA1 2b843abe875bf080d0c949663e32105a13c38122 t/14_latin1.t
-SHA1 6bc697086f8012be7df967738b560d188a775bcd t/15_prefix.t
-SHA1 f213614d8ac78feb75464c5c1f1b7ac57530a047 t/16_tied.t
-SHA1 f07ae489e00f2dbca350917828399de72fa025c2 t/17_relaxed.t
-SHA1 1523ef12859072ba900344df5f1a8439c74fbad2 t/18_json_checker.t
-SHA1 33231a52e12866a61c405496947827485ff2a811 t/19_incr.t
-SHA1 8f266979e62b50271f353e5e6905e52d9038834b t/20_faihu.t
-SHA1 1d9c81e5dfc27ff7f790354ce22af335cefe09c2 t/21_evans.t
-SHA1 3d155f37e687f929bd0cae767dc2dbf1993b73c9 t/22_comment_at_eof.t
-SHA1 ded6191143511074b0cfa5c7ff990e0cbaa11ff9 t/52_object.t
-SHA1 7be011c65f46364e10b371b399541522e519a6d1 t/96_interop.t
-SHA1 3291c73ec3a19df551d0fff59695153616fc982a t/97_unshare_hek.t
-SHA1 1bf6336a76101f747b84c35cca38c4e8bacb9224 t/98_56only.t
-SHA1 a8664530cf040e24256e3bb16def1b5876e1f33c t/99_binary.t
-SHA1 b5e9429b5aa5ee98015911e4229dede8d09b0ece t/z_kwalitee.t
-SHA1 6dfd7f5112f80b65e84916c780a0b1a71aad32dc t/z_leaktrace.t
-SHA1 993b3cef8c06a70d99829facf76140864eb57240 t/z_meta.t
-SHA1 ace5e81d6d512c2dd862f56de8d1b0d6ffb6503e t/z_perl_minimum_version.t
-SHA1 1dbe44e2091ab84d8462fda2052e35bf1354d963 t/z_pod-coverage.t
-SHA1 c8aa3903d3aba84c19bbd94d677620c758fa07d5 t/z_pod.t
-SHA1 8ad74139741a687b63c14bc6b4ae109b556f9af7 typemap
------BEGIN PGP SIGNATURE-----
-Version: GnuPG v1
-
-iEYEARECAAYFAlNb2OQACgkQmm2SYo/9yUJeTACeNgjYW9BNOOKks4QOcgzTteA5
-bEwAnisyR16Y/DvHx/08uwYeu8T674aH
-=xFTT
------END PGP SIGNATURE-----
@@ -129,7 +129,7 @@ B<Changes to JSON::XS>
package Cpanel::JSON::XS;
-our $VERSION = '3.0104';
+our $VERSION = '3.0106';
our @ISA = qw(Exporter);
our @EXPORT = qw(encode_json decode_json to_json from_json);
@@ -187,8 +187,8 @@ Except being faster.
=item $is_boolean = Cpanel::JSON::XS::is_bool $scalar
-Returns true if the passed scalar represents either Cpanel::JSON::XS::true or
-Cpanel::JSON::XS::false, two constants that act like C<1> and C<0>, respectively
+Returns true if the passed scalar represents either C<JSON::XS::true> or
+C<JSON::XS::false>, two constants that act like C<1> and C<0>, respectively
and are used to represent JSON C<true> and C<false> values in Perl.
See MAPPING, below, for more information on how JSON values are mapped to
@@ -272,7 +272,7 @@ be chained:
If C<$enable> is true (or missing), then the C<encode> method will not
generate characters outside the code range C<0..127> (which is ASCII). Any
Unicode characters outside that range will be escaped using either a
-single \uXXXX (BMP characters) or a double \uHHHH\uLLLLL escape sequence,
+single C<\uXXXX> (BMP characters) or a double C<\uHHHH\uLLLLL> escape sequence,
as per RFC4627. The resulting encoded JSON text can be treated as a native
Unicode string, an ascii-encoded, latin1-encoded or UTF-8 encoded string,
or any other superset of ASCII.
@@ -1113,12 +1113,12 @@ the JSON number will still be re-encoded as a JSON number).
Note that precision is not accuracy - binary floating point values
cannot represent most decimal fractions exactly, and when converting
-from and to floating point, Cpanel::JSON::XS only guarantees precision
+from and to floating point, C<Cpanel::JSON::XS> only guarantees precision
up to but not including the least significant bit.
=item true, false
-These JSON atoms become C<JSON::XS::true> and C<JSON::XS::false>,
+These JSON atoms become C<Cpanel::JSON::XS::true> and C<Cpanel::JSON::XS::false>,
respectively. They are overloaded to act almost exactly like the numbers
C<1> and C<0>. You can check whether a scalar is a JSON boolean by using
the C<Cpanel::JSON::XS::is_bool> function.
@@ -1174,7 +1174,8 @@ Perl array references become JSON arrays.
Other unblessed references are generally not allowed and will cause an
exception to be thrown, except for references to the integers C<0> and
C<1>, which get turned into C<false> and C<true> atoms in JSON. You can
-also use C<JSON::XS::false> and C<JSON::XS::true> to improve readability.
+also use C<Cpanel::JSON::XS::false> and C<Cpanel::JSON::XS::true> to improve
+readability.
encode_json [\0, Cpanel::JSON::XS::true] # yields [false,true]
@@ -1248,7 +1249,7 @@ tagged values.
=head3 SERIALISATION
-What happens when C<JSON::XS> encounters a Perl object depends on the
+What happens when C<Cpanel::JSON::XS> encounters a Perl object depends on the
C<allow_blessed>, C<convert_blessed> and C<allow_tags> settings, which are
used in this order:
@@ -1256,7 +1257,7 @@ used in this order:
=item 1. C<allow_tags> is enabled and the object has a C<FREEZE> method.
-In this case, C<JSON::XS> uses the L<Types::Serialiser> object
+In this case, C<Cpanel::JSON::XS> uses the L<Types::Serialiser> object
serialisation protocol to create a tagged JSON value, using a nonstandard
extension to the JSON syntax.
@@ -1307,7 +1308,7 @@ The object will be serialised as a JSON null value.
=item 4. none of the above
If none of the settings are enabled or the respective methods are missing,
-C<JSON::XS> throws an exception.
+C<Cpanel::JSON::XS> throws an exception.
=back
@@ -1324,7 +1325,7 @@ This section only considers the tagged value case: I a tagged JSON object
is encountered during decoding and C<allow_tags> is disabled, a parse
error will result (as if tagged values were not part of the grammar).
-If C<allow_tags> is enabled, C<JSON::XS> will look up the C<THAW> method
+If C<allow_tags> is enabled, C<Cpanel::JSON::XS> will look up the C<THAW> method
of the package/classname used during serialisation (it will not attempt
to load the package as a Perl module). If there is no such method, the
decoding will fail with an error.
@@ -1517,62 +1518,17 @@ If you know of other incompatibilities, please let me know.
=head2 JSON and YAML
-You often hear that JSON is a subset of YAML. This is, however, a mass
-hysteria(*) and very far from the truth (as of the time of this writing),
-so let me state it clearly: I<in general, there is no way to configure
-JSON::XS to output a data structure as valid YAML> that works in all
-cases.
-
-If you really must use Cpanel::JSON::XS to generate YAML, you should use this
-algorithm (subject to change in future versions):
+You often hear that JSON is a subset of YAML. I<in general, there is
+no way to configure JSON::XS to output a data structure as valid YAML>
+that works in all cases. If you really must use Cpanel::JSON::XS to
+generate YAML, you should use this algorithm (subject to change in
+future versions):
my $to_yaml = Cpanel::JSON::XS->new->utf8->space_after (1);
my $yaml = $to_yaml->encode ($ref) . "\n";
This will I<usually> generate JSON texts that also parse as valid
-YAML. Please note that YAML has hardcoded limits on (simple) object key
-lengths that JSON doesn't have and also has different and incompatible
-unicode character escape syntax, so you should make sure that your hash
-keys are noticeably shorter than the 1024 "stream characters" YAML allows
-and that you do not have characters with codepoint values outside the
-Unicode BMP (basic multilingual page). YAML also does not allow C<\/>
-sequences in strings (which Cpanel::JSON::XS does not I<currently> generate, but
-other JSON generators might).
-
-There might be other incompatibilities that I am not aware of (or the YAML
-specification has been changed yet again - it does so quite often). In
-general you should not try to generate YAML with a JSON generator or vice
-versa, or try to parse JSON with a YAML parser or vice versa: chances are
-high that you will run into severe interoperability problems when you
-least expect it.
-
-=over 4
-
-=item (*)
-
-I have been pressured multiple times by Brian Ingerson (one of the
-authors of the YAML specification) to remove this paragraph, despite him
-acknowledging that the actual incompatibilities exist. As I was personally
-bitten by this "JSON is YAML" lie, I refused and said I will continue to
-educate people about these issues, so others do not run into the same
-problem again and again. After this, Brian called me a (quote)I<complete
-and worthless idiot>(unquote).
-
-In my opinion, instead of pressuring and insulting people who actually
-clarify issues with YAML and the wrong statements of some of its
-proponents, I would kindly suggest reading the JSON spec (which is not
-that difficult or long) and finally make YAML compatible to it, and
-educating users about the changes, instead of spreading lies about the
-real compatibility for many I<years> and trying to silence people who
-point out that it isn't true.
-
-Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even
-though the incompatibilities have been documented (and are known to Brian)
-for many years and the spec makes explicit claims that YAML is a superset
-of JSON. It would be so easy to fix, but apparently, bullying people and
-corrupting userdata is so much easier.
-
-=back
+YAML.
=head2 SPEED
@@ -1664,8 +1620,7 @@ When you are using JSON in a protocol, talking to untrusted potentially
hostile creatures requires relatively few measures.
First of all, your JSON decoder should be secure, that is, should not have
-any buffer overflows. Obviously, this module should ensure that and I am
-trying hard on making that true, but you never know.
+any buffer overflows. Obviously, this module should ensure that.
Second, you need to avoid resource-starving attacks. That means you should
limit the size of JSON texts you accept, or make sure then when your
@@ -1676,7 +1631,7 @@ it into a Perl structure. While JSON::XS can check the size of the JSON
text, it might be too late when you already have it in memory, so you
might want to check the size before you accept the string.
-Third, JSON::XS recurses using the C stack when decoding objects and
+Third, Cpanel::JSON::XS recurses using the C stack when decoding objects and
arrays. The C stack is a limited resource: for instance, on my amd64
machine with 8MB of stack size I can decode around 180k nested arrays but
only 14k nested JSON objects (due to perl itself recursing deeply on croak
@@ -1685,15 +1640,12 @@ conservative, the default nesting limit is set to 512. If your process
has a smaller stack, you should adjust this setting accordingly with the
C<max_depth> method.
-Something else could bomb you, too, that I forgot to think of. In that
-case, you get to keep the pieces. I am always open for hints, though...
-
-Also keep in mind that JSON::XS might leak contents of your Perl data
+Also keep in mind that Cpanel::JSON::XS might leak contents of your Perl data
structures in its error messages, so when you serialise sensitive
information you might want to make sure that exceptions thrown by JSON::XS
will not end up in front of untrusted eyes.
-If you are using JSON::XS to return packets to consumption
+If you are using Cpanel::JSON::XS to return packets to consumption
by JavaScript scripts in a browser you should have a look at
L<http://blog.archive.jpsykes.com/47/practical-csrf-and-json-security/> to
see whether you are vulnerable to some common attack vectors (which really
@@ -1705,11 +1657,11 @@ security right).
=head1 THREADS
Cpanel::JSON::XS has experimental ithreads support, unlike JSON::XS. If you
-encouter any bugs with thread support please report them.
+encounter any bugs with thread support please report them.
=head1 BUGS
-While the goal of the JSON::XS module is to be correct, that
+While the goal of the Cpanel::JSON::XS module is to be correct, that
unfortunately does not mean it's bug-free, only that the author thinks
its design is bug-free. If you keep reporting bugs they will be fixed
swiftly, though.
@@ -4,6 +4,7 @@ use Test::More;
use strict;
BEGIN { plan tests => 8 };
use Cpanel::JSON::XS;
+use Config ();
#########################
my ($js,$obj);
@@ -25,8 +26,11 @@ $js = q|[1.23E-4]|;
$obj = $pc->decode($js);
is($obj->[0], 0.000123, 'digit 1.23E-4');
$js = $pc->encode($obj);
-is($js,'[0.000123]', 'digit 1.23E-4');
-
+if ($] < 5.007 and $Config::Config{d_Gconvert} =~ /^g/) {
+ is($js,'[1.23e-04]', 'digit 1.23e-4 v5.6');
+} else {
+ is($js,'[0.000123]', 'digit 1.23E-4');
+}
$js = q|[1.01e+30]|;
$obj = $pc->decode($js);