[ViewVC] Diff of: cvs/JSON-XS/XS.pm

Comparing JSON-XS/XS.pm (file contents):
Revision 1.168 by root, Thu Nov 15 20:13:03 2018 UTC vs.
Revision 1.175 by root, Wed Mar 6 07:32:06 2019 UTC

…		…
35		35
36	This module converts Perl data structures to JSON and vice versa. Its	36	This module converts Perl data structures to JSON and vice versa. Its
37	primary goal is to be I<correct> and its secondary goal is to be	37	primary goal is to be I<correct> and its secondary goal is to be
38	I<fast>. To reach the latter goal it was written in C.	38	I<fast>. To reach the latter goal it was written in C.
39		39
40	Beginning with version 2.0 of the JSON module, when both JSON and
41	JSON::XS are installed, then JSON will fall back on JSON::XS (this can be
42	overridden) with no overhead due to emulation (by inheriting constructor
43	and methods). If JSON::XS is not available, it will fall back to the
44	compatible JSON::PP module as backend, so using JSON instead of JSON::XS
45	gives you a portable JSON API that can be fast when you need it and
46	doesn't require a C compiler when that is a problem.
47
48	As this is the n-th-something JSON module on CPAN, what was the reason
49	to write yet another JSON module? While it seems there are many JSON
50	modules, none of them correctly handle all corner cases, and in most cases
51	their maintainers are unresponsive, gone missing, or not listening to bug
52	reports for other reasons.
53
54	See MAPPING, below, on how JSON::XS maps perl values to JSON values and	40	See MAPPING, below, on how JSON::XS maps perl values to JSON values and
55	vice versa.	41	vice versa.
56		42
57	=head2 FEATURES	43	=head2 FEATURES
58		44
59	=over 4	45	=over
60		46
61	=item * correct Unicode handling	47	=item * correct Unicode handling
62		48
63	This module knows how to handle Unicode, documents how and when it does	49	This module knows how to handle Unicode, documents how and when it does
64	so, and even documents what "correct" means.	50	so, and even documents what "correct" means.
…		…
101		87
102	package JSON::XS;	88	package JSON::XS;
103		89
104	use common::sense;	90	use common::sense;
105		91
106	our $VERSION = 3.04;	92	our $VERSION = '4.02';
107	our @ISA = qw(Exporter);	93	our @ISA = qw(Exporter);
108		94
109	our @EXPORT = qw(encode_json decode_json);	95	our @EXPORT = qw(encode_json decode_json);
110		96
111	use Exporter;	97	use Exporter;
…		…
116	=head1 FUNCTIONAL INTERFACE	102	=head1 FUNCTIONAL INTERFACE
117		103
118	The following convenience methods are provided by this module. They are	104	The following convenience methods are provided by this module. They are
119	exported by default:	105	exported by default:
120		106
121	=over 4	107	=over
122		108
123	=item $json_text = encode_json $perl_scalar	109	=item $json_text = encode_json $perl_scalar
124		110
125	Converts the given Perl data structure to a UTF-8 encoded, binary string	111	Converts the given Perl data structure to a UTF-8 encoded, binary string
126	(that is, the string contains octets only). Croaks on error.	112	(that is, the string contains octets only). Croaks on error.
…		…
149	=head1 A FEW NOTES ON UNICODE AND PERL	135	=head1 A FEW NOTES ON UNICODE AND PERL
150		136
151	Since this often leads to confusion, here are a few very clear words on	137	Since this often leads to confusion, here are a few very clear words on
152	how Unicode works in Perl, modulo bugs.	138	how Unicode works in Perl, modulo bugs.
153		139
154	=over 4	140	=over
155		141
156	=item 1. Perl strings can store characters with ordinal values > 255.	142	=item 1. Perl strings can store characters with ordinal values > 255.
157		143
158	This enables you to store Unicode characters as single characters in a	144	This enables you to store Unicode characters as single characters in a
159	Perl string - very natural.	145	Perl string - very natural.
…		…
197	=head1 OBJECT-ORIENTED INTERFACE	183	=head1 OBJECT-ORIENTED INTERFACE
198		184
199	The object oriented interface lets you configure your own encoding or	185	The object oriented interface lets you configure your own encoding or
200	decoding style, within the limits of supported formats.	186	decoding style, within the limits of supported formats.
201		187
202	=over 4	188	=over
203		189
204	=item $json = new JSON::XS	190	=item $json = new JSON::XS
205		191
206	Creates a new JSON::XS object that can be used to de/encode JSON	192	Creates a new JSON::XS object that can be used to de/encode JSON
207	strings. All boolean flags described below are by default I<disabled>.	193	strings. All boolean flags described below are by default I<disabled>
		194	(with the exception of C<allow_nonref>, which defaults to I<enabled> since
		195	version C<4.0>).
208		196
209	The mutators for flags all return the JSON object again and thus calls can	197	The mutators for flags all return the JSON object again and thus calls can
210	be chained:	198	be chained:
211		199
212	my $json = JSON::XS->new->utf8->space_after->encode ({a => [1,2]})	200	my $json = JSON::XS->new->utf8->space_after->encode ({a => [1,2]})
…		…
375	If C<$enable> is false (the default), then C<decode> will only accept	363	If C<$enable> is false (the default), then C<decode> will only accept
376	valid JSON texts.	364	valid JSON texts.
377		365
378	Currently accepted extensions are:	366	Currently accepted extensions are:
379		367
380	=over 4	368	=over
381		369
382	=item * list items can have an end-comma	370	=item * list items can have an end-comma
383		371
384	JSON I<separates> array elements and key-value pairs with commas. This	372	JSON I<separates> array elements and key-value pairs with commas. This
385	can be annoying if you write JSON texts manually and want to be able to	373	can be annoying if you write JSON texts manually and want to be able to
…		…
441		429
442	=item $json = $json->allow_nonref ([$enable])	430	=item $json = $json->allow_nonref ([$enable])
443		431
444	=item $enabled = $json->get_allow_nonref	432	=item $enabled = $json->get_allow_nonref
445		433
		434	Unlike other boolean options, this opotion is enabled by default beginning
		435	with version C<4.0>. See L<SECURITY CONSIDERATIONS> for the gory details.
		436
446	If C<$enable> is true (or missing), then the C<encode> method can convert a	437	If C<$enable> is true (or missing), then the C<encode> method can convert a
447	non-reference into its corresponding string, number or null JSON value,	438	non-reference into its corresponding string, number or null JSON value,
448	which is an extension to RFC4627. Likewise, C<decode> will accept those JSON	439	which is an extension to RFC4627. Likewise, C<decode> will accept those JSON
449	values instead of croaking.	440	values instead of croaking.
450		441
451	If C<$enable> is false, then the C<encode> method will croak if it isn't	442	If C<$enable> is false, then the C<encode> method will croak if it isn't
452	passed an arrayref or hashref, as JSON texts must either be an object	443	passed an arrayref or hashref, as JSON texts must either be an object
453	or array. Likewise, C<decode> will croak if given something that is not a	444	or array. Likewise, C<decode> will croak if given something that is not a
454	JSON object or array.	445	JSON object or array.
455		446
456	Example, encode a Perl scalar as JSON value with enabled C<allow_nonref>,	447	Example, encode a Perl scalar as JSON value without enabled C<allow_nonref>,
457	resulting in an invalid JSON text:	448	resulting in an error:
458		449
459	JSON::XS->new->allow_nonref->encode ("Hello, World!")	450	JSON::XS->new->allow_nonref (0)->encode ("Hello, World!")
460	=> "Hello, World!"	451	=> hash- or arrayref expected...
461		452
462	=item $json = $json->allow_unknown ([$enable])	453	=item $json = $json->allow_unknown ([$enable])
463		454
464	=item $enabled = $json->get_allow_unknown	455	=item $enabled = $json->get_allow_unknown
465		456
…		…
530	them via a call to the C<THAW> method.	521	them via a call to the C<THAW> method.
531		522
532	If C<$enable> is false (the default), then C<encode> will not consider	523	If C<$enable> is false (the default), then C<encode> will not consider
533	this type of conversion, and tagged JSON values will cause a parse error	524	this type of conversion, and tagged JSON values will cause a parse error
534	in C<decode>, as if tags were not part of the grammar.	525	in C<decode>, as if tags were not part of the grammar.
		526
		527	=item $json->boolean_values ([$false, $true])
		528
		529	=item ($false, $true) = $json->get_boolean_values
		530
		531	By default, JSON booleans will be decoded as overloaded
		532	C<$Types::Serialiser::false> and C<$Types::Serialiser::true> objects.
		533
		534	With this method you can specify your own boolean values for decoding -
		535	on decode, JSON C<false> will be decoded as a copy of C<$false>, and JSON
		536	C<true> will be decoded as C<$true> ("copy" here is the same thing as
		537	assigning a value to another variable, i.e. C<$copy = $false>).
		538
		539	Calling this method without any arguments will reset the booleans
		540	to their default values.
		541
		542	C<get_boolean_values> will return both C<$false> and C<$true> values, or
		543	the empty list when they are set to the default.
535		544
536	=item $json = $json->filter_json_object ([$coderef->($hashref)])	545	=item $json = $json->filter_json_object ([$coderef->($hashref)])
537		546
538	When C<$coderef> is specified, it will be called from C<decode> each	547	When C<$coderef> is specified, it will be called from C<decode> each
539	time it decodes a JSON object. The only argument is a reference to	548	time it decodes a JSON object. The only argument is a reference to
…		…
724	to set resource limits (e.g. C<max_size>) to ensure the parser will stop	733	to set resource limits (e.g. C<max_size>) to ensure the parser will stop
725	parsing in the presence if syntax errors.	734	parsing in the presence if syntax errors.
726		735
727	The following methods implement this incremental parser.	736	The following methods implement this incremental parser.
728		737
729	=over 4	738	=over
730		739
731	=item [void, scalar or list context] = $json->incr_parse ([$string])	740	=item [void, scalar or list context] = $json->incr_parse ([$string])
732		741
733	This is the central parsing function. It can both append new text and	742	This is the central parsing function. It can both append new text and
734	extract objects from the stream accumulated so far (both of these	743	extract objects from the stream accumulated so far (both of these
…		…
801		810
802	=back	811	=back
803		812
804	=head2 LIMITATIONS	813	=head2 LIMITATIONS
805		814
806	All options that affect decoding are supported, except	815	The incremental parser is a non-exact parser: it works by gathering as
807	C<allow_nonref>. The reason for this is that it cannot be made to work	816	much text as possible that I<could> be a valid JSON text, followed by
808	sensibly: JSON objects and arrays are self-delimited, i.e. you can	817	trying to decode it.
809	concatenate them back to back and still decode them perfectly. This does
810	not hold true for JSON numbers, however.
811		818
812	For example, is the string C<1> a single JSON number, or is it simply the	819	That means it sometimes needs to read more data than strictly necessary to
813	start of C<12>? Or is C<12> a single JSON number, or the concatenation	820	diagnose an invalid JSON text. For example, after parsing the following
814	of C<1> and C<2>? In neither case you can tell, and this is why JSON::XS	821	fragment, the parser I<could> stop with an error, as this fragment
815	takes the conservative route and disallows this case.	822	I<cannot> be the beginning of a valid JSON text:
		823
		824	[,
		825
		826	In reality, hopwever, the parser might continue to read data until a
		827	length limit is exceeded or it finds a closing bracket.
816		828
817	=head2 EXAMPLES	829	=head2 EXAMPLES
818		830
819	Some examples will make all this clearer. First, a simple example that	831	Some examples will make all this clearer. First, a simple example that
820	works similarly to C<decode_prefix>: We want to decode the JSON object at	832	works similarly to C<decode_prefix>: We want to decode the JSON object at
…		…
964	refers to the abstract Perl language itself.	976	refers to the abstract Perl language itself.
965		977
966		978
967	=head2 JSON -> PERL	979	=head2 JSON -> PERL
968		980
969	=over 4	981	=over
970		982
971	=item object	983	=item object
972		984
973	A JSON object becomes a reference to a hash in Perl. No ordering of object	985	A JSON object becomes a reference to a hash in Perl. No ordering of object
974	keys is preserved (JSON does not preserve object key ordering itself).	986	keys is preserved (JSON does not preserve object key ordering itself).
…		…
1042		1054
1043	The mapping from Perl to JSON is slightly more difficult, as Perl is a	1055	The mapping from Perl to JSON is slightly more difficult, as Perl is a
1044	truly typeless language, so we can only guess which JSON type is meant by	1056	truly typeless language, so we can only guess which JSON type is meant by
1045	a Perl value.	1057	a Perl value.
1046		1058
1047	=over 4	1059	=over
1048		1060
1049	=item hash references	1061	=item hash references
1050		1062
1051	Perl hash references become JSON objects. As there is no inherent	1063	Perl hash references become JSON objects. As there is no inherent
1052	ordering in hash keys (or JSON objects), they will usually be encoded	1064	ordering in hash keys (or JSON objects), they will usually be encoded
…		…
1141		1153
1142	What happens when C<JSON::XS> encounters a Perl object depends on the	1154	What happens when C<JSON::XS> encounters a Perl object depends on the
1143	C<allow_blessed>, C<convert_blessed> and C<allow_tags> settings, which are	1155	C<allow_blessed>, C<convert_blessed> and C<allow_tags> settings, which are
1144	used in this order:	1156	used in this order:
1145		1157
1146	=over 4	1158	=over
1147		1159
1148	=item 1. C<allow_tags> is enabled and the object has a C<FREEZE> method.	1160	=item 1. C<allow_tags> is enabled and the object has a C<FREEZE> method.
1149		1161
1150	In this case, C<JSON::XS> uses the L<Types::Serialiser> object	1162	In this case, C<JSON::XS> uses the L<Types::Serialiser> object
1151	serialisation protocol to create a tagged JSON value, using a nonstandard	1163	serialisation protocol to create a tagged JSON value, using a nonstandard
…		…
1262	takes those codepoint numbers and I<encodes> them, in our case into	1274	takes those codepoint numbers and I<encodes> them, in our case into
1263	octets. Unicode is (among other things) a codeset, UTF-8 is an encoding,	1275	octets. Unicode is (among other things) a codeset, UTF-8 is an encoding,
1264	and ISO-8859-1 (= latin 1) and ASCII are both codesets I<and> encodings at	1276	and ISO-8859-1 (= latin 1) and ASCII are both codesets I<and> encodings at
1265	the same time, which can be confusing.	1277	the same time, which can be confusing.
1266		1278
1267	=over 4	1279	=over
1268		1280
1269	=item C<utf8> flag disabled	1281	=item C<utf8> flag disabled
1270		1282
1271	When C<utf8> is disabled (the default), then C<encode>/C<decode> generate	1283	When C<utf8> is disabled (the default), then C<encode>/C<decode> generate
1272	and expect Unicode strings, that is, characters with high ordinal Unicode	1284	and expect Unicode strings, that is, characters with high ordinal Unicode
…		…
1431	general you should not try to generate YAML with a JSON generator or vice	1443	general you should not try to generate YAML with a JSON generator or vice
1432	versa, or try to parse JSON with a YAML parser or vice versa: chances are	1444	versa, or try to parse JSON with a YAML parser or vice versa: chances are
1433	high that you will run into severe interoperability problems when you	1445	high that you will run into severe interoperability problems when you
1434	least expect it.	1446	least expect it.
1435		1447
1436	=over 4	1448	=over
1437		1449
1438	=item (*)	1450	=item (*)
1439		1451
1440	I have been pressured multiple times by Brian Ingerson (one of the	1452	I have been pressured multiple times by Brian Ingerson (one of the
1441	authors of the YAML specification) to remove this paragraph, despite him	1453	authors of the YAML specification) to remove this paragraph, despite him
…		…
1567	are browser design bugs, but it is still you who will have to deal with	1579	are browser design bugs, but it is still you who will have to deal with
1568	it, as major browser developers care only for features, not about getting	1580	it, as major browser developers care only for features, not about getting
1569	security right).	1581	security right).
1570		1582
1571		1583
1572	=head1 "OLD" VS. "NEW" JSON (RFC 4627 VS. RFC 7159)	1584	=head2 "OLD" VS. "NEW" JSON (RFC4627 VS. RFC7159)
1573		1585
1574	TL;DR: Due to security concerns, JSON::XS will not allow scalar data in	1586	JSON originally required JSON texts to represent an array or object -
1575	JSON texts by default - you need to create your own JSON::XS object and	1587	scalar values were explicitly not allowed. This has changed, and versions
1576	enable C<allow_nonref>:	1588	of JSON::XS beginning with C<4.0> reflect this by allowing scalar values
		1589	by default.
1577		1590
		1591	One reason why one might not want this is that this removes a fundamental
		1592	property of JSON texts, namely that they are self-delimited and
		1593	self-contained, or in other words, you could take any number of "old"
		1594	JSON texts and paste them together, and the result would be unambiguously
		1595	parseable:
1578		1596
		1597	[1,3]{"k":5}[][null] # four JSON texts, without doubt
		1598
		1599	By allowing scalars, this property is lost: in the following example, is
		1600	this one JSON text (the number 12) or two JSON texts (the numbers 1 and
		1601	2):
		1602
		1603	12 # could be 12, or 1 and 2
		1604
		1605	Another lost property of "old" JSON is that no lookahead is required to
		1606	know the end of a JSON text, i.e. the JSON text definitely ended at the
		1607	last C<]> or C<}> character, there was no need to read extra characters.
		1608
		1609	For example, a viable network protocol with "old" JSON was to simply
		1610	exchange JSON texts without delimiter. For "new" JSON, you have to use a
		1611	suitable delimiter (such as a newline) after every JSON text or ensure you
		1612	never encode/decode scalar values.
		1613
		1614	Most protocols do work by only transferring arrays or objects, and the
		1615	easiest way to avoid problems with the "new" JSON definition is to
		1616	explicitly disallow scalar values in your encoder and decoder:
		1617
1579	my $json = JSON::XS->new->allow_nonref;	1618	$json_coder = JSON::XS->new->allow_nonref (0)
1580		1619
1581	$text = $json->encode ($data);	1620	This is a somewhat unhappy situation, and the blame can fully be put on
1582	$data = $json->decode ($text);	1621	JSON's inmventor, Douglas Crockford, who unilaterally changed the format
		1622	in 2006 without consulting the IETF, forcing the IETF to either fork the
		1623	format or go with it (as I was told, the IETF wasn't amused).
1583		1624
1584	The long version: JSON being an important and supposedly stable format,
1585	the IETF standardised it as RFC 4627 in 2006. Unfortunately, the inventor
1586	of JSON, Dougles Crockford, unilaterally changed the definition of JSON in
1587	javascript. Rather than create a fork, the IETF decided to standardise the
1588	new syntax (apparently, so Iw as told, without finding it very amusing).
1589		1625
1590	The biggest difference between thed original JSON and the new JSON is that	1626	=head1 RELATIONSHIP WITH I-JSON
1591	the new JSON supports scalars (anything other than arrays and objects) at
1592	the toplevel of a JSON text. While this is strictly backwards compatible
1593	to older versions, it breaks a number of protocols that relied on sending
1594	JSON back-to-back, and is a minor security concern.
1595		1627
1596	For example, imagine you have two banks communicating, and on one side,	1628	JSON is a somewhat sloppily-defined format - it carries around obvious
1597	trhe JSON coder gets upgraded. Two messages, such as C<10> and C<1000>	1629	Javascript baggage, such as not really defining number range, probably
1598	might then be confused to mean C<101000>, something that couldn't happen	1630	because Javascript only has one type of numbers: IEEE 64 bit floats
1599	in the original JSON, because niether of these messages would be valid	1631	("binary64").
1600	JSON.
1601		1632
1602	If one side accepts these messages, then an upgrade in the coder on either	1633	For this reaosn, RFC7493 defines "Internet JSON", which is a restricted
1603	side could result in this becoming exploitable.	1634	subset of JSON that is supposedly more interoperable on the internet.
1604		1635
1605	This module has always allowed these messages as an optional extension, by	1636	While C<JSON::XS> does not offer specific support for I-JSON, it of course
1606	default disabled. The security concerns are the reason why the default is	1637	accepts valid I-JSON and by default implements some of the limitations
1607	still disabled, but future versions might/will likely upgrade to the newer	1638	of I-JSON, such as parsing numbers as perl numbers, which are usually a
1608	RFC as default format, so you are advised to check your implementation	1639	superset of binary64 numbers.
1609	and/or override the default with C<< ->allow_nonref (0) >> to ensure that	1640
1610	future versions are safe.	1641	To generate I-JSON, follow these rules:
		1642
		1643	=over
		1644
		1645	=item * always generate UTF-8
		1646
		1647	I-JSON must be encoded in UTF-8, the default for C<encode_json>.
		1648
		1649	=item * numbers should be within IEEE 754 binary64 range
		1650
		1651	Basically all existing perl installations use binary64 to represent
		1652	floating point numbers, so all you need to do is to avoid large integers.
		1653
		1654	=item * objects must not have duplicate keys
		1655
		1656	This is trivially done, as C<JSON::XS> does not allow duplicate keys.
		1657
		1658	=item * do not generate scalar JSON texts, use C<< ->allow_nonref (0) >>
		1659
		1660	I-JSON strongly requests you to only encode arrays and objects into JSON.
		1661
		1662	=item * times should be strings in ISO 8601 format
		1663
		1664	There are a myriad of modules on CPAN dealing with ISO 8601 - search for
		1665	C<ISO8601> on CPAN and use one.
		1666
		1667	=item * encode binary data as base64
		1668
		1669	While it's tempting to just dump binary data as a string (and let
		1670	C<JSON::XS> do the escaping), for I-JSON, it's I<recommended> to encode
		1671	binary data as base64.
		1672
		1673	=back
		1674
		1675	There are some other considerations - read RFC7493 for the details if
		1676	interested.
1611		1677
1612		1678
1613	=head1 INTEROPERABILITY WITH OTHER MODULES	1679	=head1 INTEROPERABILITY WITH OTHER MODULES
1614		1680
1615	C<JSON::XS> uses the L<Types::Serialiser> module to provide boolean	1681	C<JSON::XS> uses the L<Types::Serialiser> module to provide boolean
…		…
1678		1744
1679	Again, this has some limitations - the magic string must not be encoded	1745	Again, this has some limitations - the magic string must not be encoded
1680	with character escapes, and the constructor arguments must be non-empty.	1746	with character escapes, and the constructor arguments must be non-empty.
1681		1747
1682		1748
1683	=head1 RFC7159
1684
1685	Since this module was written, Google has written a new JSON RFC, RFC 7159
1686	(and RFC7158). Unfortunately, this RFC breaks compatibility with both the
1687	original JSON specification on www.json.org and RFC4627.
1688
1689	As far as I can see, you can get partial compatibility when parsing by
1690	using C<< ->allow_nonref >>. However, consider the security implications
1691	of doing so.
1692
1693	I haven't decided yet when to break compatibility with RFC4627 by default
1694	(and potentially leave applications insecure) and change the default to
1695	follow RFC7159, but application authors are well advised to call C<<
1696	->allow_nonref(0) >> even if this is the current default, if they cannot
1697	handle non-reference values, in preparation for the day when the default
1698	will change.
1699
1700
1701	=head1 (I-)THREADS	1749	=head1 (I-)THREADS
1702		1750
1703	This module is I<not> guaranteed to be ithread (or MULTIPLICITY-) safe	1751	This module is I<not> guaranteed to be ithread (or MULTIPLICITY-) safe
1704	and there are no plans to change this. Note that perl's builtin so-called	1752	and there are no plans to change this. Note that perl's builtin so-called
1705	threads/ithreads are officially deprecated and should not be used.	1753	threads/ithreads are officially deprecated and should not be used.
…		…
1719	categories you need, such as C<LC_MESSAGES> or C<LC_CTYPE>.	1767	categories you need, such as C<LC_MESSAGES> or C<LC_CTYPE>.
1720		1768
1721	If you need C<LC_NUMERIC>, you should enable it only around the code that	1769	If you need C<LC_NUMERIC>, you should enable it only around the code that
1722	actually needs it (avoiding stringification of numbers), and restore it	1770	actually needs it (avoiding stringification of numbers), and restore it
1723	afterwards.	1771	afterwards.
		1772
		1773
		1774	=head1 SOME HISTORY
		1775
		1776	At the time this module was created there already were a number of JSON
		1777	modules available on CPAN, so what was the reason to write yet another
		1778	JSON module? While it seems there are many JSON modules, none of them
		1779	correctly handled all corner cases, and in most cases their maintainers
		1780	are unresponsive, gone missing, or not listening to bug reports for other
		1781	reasons.
		1782
		1783	Beginning with version 2.0 of the JSON module, when both JSON and
		1784	JSON::XS are installed, then JSON will fall back on JSON::XS (this can be
		1785	overridden) with no overhead due to emulation (by inheriting constructor
		1786	and methods). If JSON::XS is not available, it will fall back to the
		1787	compatible JSON::PP module as backend, so using JSON instead of JSON::XS
		1788	gives you a portable JSON API that can be fast when you need it and
		1789	doesn't require a C compiler when that is a problem.
		1790
		1791	Somewhere around version 3, this module was forked into
		1792	C<Cpanel::JSON::XS>, because its maintainer had serious trouble
		1793	understanding JSON and insisted on a fork with many bugs "fixed" that
		1794	weren't actually bugs, while spreading FUD about this module without
		1795	actually giving any details on his accusations. You be the judge, but
		1796	in my personal opinion, if you want quality, you will stay away from
		1797	dangerous forks like that.
1724		1798
1725		1799
1726	=head1 BUGS	1800	=head1 BUGS
1727		1801
1728	While the goal of this module is to be correct, that unfortunately does	1802	While the goal of this module is to be correct, that unfortunately does

Diff Legend

-–
+Removed lines
-+
+Added lines
-<
+Changed lines
->
+Changed lines

Comparing JSON-XS/XS.pm (file contents): Revision 1.168 by root, Thu Nov 15 20:13:03 2018 UTC vs. Revision 1.175 by root, Wed Mar 6 07:32:06 2019 UTC

Diff Legend

Comparing JSON-XS/XS.pm (file contents):
Revision 1.168 by root, Thu Nov 15 20:13:03 2018 UTC vs.
Revision 1.175 by root, Wed Mar 6 07:32:06 2019 UTC