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

Comparing JSON-XS/XS.pm (file contents):
Revision 1.131 by root, Thu Mar 11 19:31:37 2010 UTC vs.
Revision 1.141 by root, Fri Oct 25 19:53:08 2013 UTC

 this module usually compares favourably in terms of speed, too.
 =item * simple to use
 This module has both a simple functional interface as well as an object
-oriented interface interface.
+oriented interface.
 =item * reasonably versatile output formats
 You can choose between the most compact guaranteed-single-line format
 possible (nice for simple line-based protocols), a pure-ASCII format
 package JSON::XS;
 use common::sense;
-our $VERSION = '2.28';
+our $VERSION = 2.34;
 our @ISA = qw(Exporter);
-our @EXPORT = qw(encode_json decode_json to_json from_json);
+our @EXPORT = qw(encode_json decode_json);
-sub to_json($) {
-   require Carp;
-   Carp::croak ("JSON::XS::to_json has been renamed to encode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call");
-}
-sub from_json($) {
-   require Carp;
-   Carp::croak ("JSON::XS::from_json has been renamed to decode_json, either downgrade to pre-2.0 versions of JSON::XS or rename the call");
-}
 use Exporter;
 use XSLoader;
 =head1 FUNCTIONAL INTERFACE
 If C<$enable> is true (or missing), then the C<encode> method will output JSON objects
 by sorting their keys. This is adding a comparatively high overhead.
 If C<$enable> is false, then the C<encode> method will output key-value
 pairs in the order Perl stores them (which will likely change between runs
-of the same script).
+of the same script, and can change even within the same run from 5.18
+onwards).
 This option is useful if you want the same data structure to be encoded as
 the same JSON text (given the same overall settings). If it is disabled,
 the same hash might be encoded differently even if contains the same data,
 as key-value pairs have no inherent ordering in Perl.
 See SECURITY CONSIDERATIONS, below, for more info on why this is useful.
 =item $json_text = $json->encode ($perl_scalar)
-Converts the given Perl data structure (a simple scalar or a reference
+Converts the given Perl value or data structure to its JSON
-to a hash or array) to its JSON representation. Simple scalars will be
+representation. Croaks on error.
-converted into JSON string or number sequences, while references to arrays
-become JSON arrays and references to hashes become JSON objects. Undefined
-Perl values (e.g. C<undef>) become JSON C<null> values. Neither C<true>
-nor C<false> values will be generated.
 =item $perl_scalar = $json->decode ($json_text)
 The opposite of C<encode>: expects a JSON text and tries to parse it,
 returning the resulting simple scalar or reference. Croaks on error.
-JSON numbers and strings become simple Perl scalars. JSON arrays become
-Perl arrayrefs and JSON objects become Perl hashrefs. C<true> becomes
-C<1>, C<false> becomes C<0> and C<null> becomes C<undef>.
 =item ($perl_scalar, $characters) = $json->decode_prefix ($json_text)
 This works like the C<decode> method, but instead of raising an exception
 when there is trailing garbage after the first JSON object, it will
 calls).
 JSON::XS will only attempt to parse the JSON text once it is sure it
 has enough text to get a decisive result, using a very simple but
 truly incremental parser. This means that it sometimes won't stop as
-early as the full parser, for example, it doesn't detect parenthese
+early as the full parser, for example, it doesn't detect mismatched
-mismatches. The only thing it guarantees is that it starts decoding as
+parentheses. The only thing it guarantees is that it starts decoding as
 soon as a syntactically valid JSON text has been seen. This means you need
 to set resource limits (e.g. C<max_size>) to ensure the parser will stop
 parsing in the presence if syntax errors.
 The following methods implement this incremental parser.
 If the method is called in scalar context, then it will try to extract
 exactly I<one> JSON object. If that is successful, it will return this
 object, otherwise it will return C<undef>. If there is a parse error,
 this method will croak just as C<decode> would do (one can then use
-C<incr_skip> to skip the errornous part). This is the most common way of
+C<incr_skip> to skip the erroneous part). This is the most common way of
 using the method.
 And finally, in list context, it will try to extract as many objects
 from the stream as it can find and return them, or the empty list
 otherwise. For this to work, there must be no separators between the JSON
 C<incr_parse> died, in which case the input buffer and incremental parser
 state is left unchanged, to skip the text parsed so far and to reset the
 parse state.
 The difference to C<incr_reset> is that only text until the parse error
-occured is removed.
+occurred is removed.
 =item $json->incr_reset
 This completely resets the incremental parser, that is, after this call,
 it will be as if the parser had never parsed anything.
 If the number consists of digits only, JSON::XS will try to represent
 it as an integer value. If that fails, it will try to represent it as
 a numeric (floating point) value if that is possible without loss of
 precision. Otherwise it will preserve the number as a string value (in
 which case you lose roundtripping ability, as the JSON number will be
-re-encoded toa JSON string).
+re-encoded to a JSON string).
 Numbers containing a fractional or exponential part will always be
 represented as numeric (floating point) values, possibly at a loss of
 precision (in which case you might lose perfect roundtripping ability, but
 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, JSON::XS only guarantees precision up to but not including
-the leats significant bit.
+the least significant bit.
 =item true, false
 These JSON atoms become C<JSON::XS::true> and C<JSON::XS::false>,
 respectively. They are overloaded to act almost exactly like the numbers
 =item C<utf8> flag disabled
 When C<utf8> is disabled (the default), then C<encode>/C<decode> generate
 and expect Unicode strings, that is, characters with high ordinal Unicode
 values (> 255) will be encoded as such characters, and likewise such
-characters are decoded as-is, no canges to them will be done, except
+characters are decoded as-is, no changes to them will be done, except
 "(re-)interpreting" them as Unicode codepoints or Unicode characters,
 respectively (to Perl, these are the same thing in strings unless you do
 funny/weird/dumb stuff).
 This is useful when you want to do the encoding yourself (e.g. when you
 well - using C<eval> naively simply I<will> cause problems.
 Another problem is that some javascript implementations reserve
 some property names for their own purposes (which probably makes
 them non-ECMAscript-compliant). For example, Iceweasel reserves the
-C<__proto__> property name for it's own purposes.
+C<__proto__> property name for its own purposes.
 If that is a problem, you could parse try to filter the resulting JSON
 output for these property strings, e.g.:
    $json =~ s/"__proto__"\s*:/"__proto__renamed":/g;
 This works because C<__proto__> is not valid outside of strings, so every
-occurence of C<"__proto__"\s*:> must be a string used as property name.
+occurrence of C<"__proto__"\s*:> must be a string used as property name.
 If you know of other incompatibilities, please let me know.
 =head2 JSON and YAML
 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 incomaptible with JSON, even
+Addendum/2009: the YAML 1.2 spec is still incompatible with JSON, even
-though the incompatibilities have been documented (and are known to
+though the incompatibilities have been documented (and are known to Brian)
-Brian) for many years and the spec makes explicit claims that YAML is a
+for many years and the spec makes explicit claims that YAML is a superset
-superset of JSON. It would be so easy to fix, but apparently, bullying and
+of JSON. It would be so easy to fix, but apparently, bullying people and
 corrupting userdata is so much easier.
 =back
 process simulations - use fork, it's I<much> faster, cheaper, better).
 (It might actually work, but you have been warned).
+=head1 THE PERILS OF SETLOCALE
+Sometimes people avoid the Perl locale support and directly call the
+system's setlocale function with C<LC_ALL>.
+This breaks both perl and modules such as JSON::XS, as stringification of
+numbers no longer works correctly (e.g. C<$x = 0.1; print "$x"+1> might
+print C<1>, and JSON::XS might output illegal JSON as JSON::XS relies on
+perl to stringify numbers).
+The solution is simple: don't call C<setlocale>, or use it for only those
+categories you need, such as C<LC_MESSAGES> or C<LC_CTYPE>.
+If you need C<LC_NUMERIC>, you should enable it only around the code that
+actually needs it (avoiding stringification of numbers), and restore it
+afterwards.
 =head1 BUGS
 While the goal of this module is to be correct, that unfortunately does
 not mean it's bug-free, only that I think its design is bug-free. If you
 keep reporting bugs they will be fixed swiftly, though.

Diff Legend

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

Comparing JSON-XS/XS.pm (file contents): Revision 1.131 by root, Thu Mar 11 19:31:37 2010 UTC vs. Revision 1.141 by root, Fri Oct 25 19:53:08 2013 UTC

Diff Legend

Comparing JSON-XS/XS.pm (file contents):
Revision 1.131 by root, Thu Mar 11 19:31:37 2010 UTC vs.
Revision 1.141 by root, Fri Oct 25 19:53:08 2013 UTC