Make hashtable less generic
[jansson.git] / doc / conformance.rst
1 .. _rfc-conformance:
2
3 ***************
4 RFC Conformance
5 ***************
6
7 JSON is specified in :rfc:`4627`, *"The application/json Media Type
8 for JavaScript Object Notation (JSON)"*.
9
10 Character Encoding
11 ==================
12
13 Jansson only supports UTF-8 encoded JSON texts. It does not support or
14 auto-detect any of the other encodings mentioned in the RFC, namely
15 UTF-16LE, UTF-16BE, UTF-32LE or UTF-32BE. Pure ASCII is supported, as
16 it's a subset of UTF-8.
17
18 Strings
19 =======
20
21 JSON strings are mapped to C-style null-terminated character arrays,
22 and UTF-8 encoding is used internally. Strings may not contain
23 embedded null characters, not even escaped ones.
24
25 For example, trying to decode the following JSON text leads to a parse
26 error::
27
28     ["this string contains the null character: \u0000"]
29
30 All other Unicode codepoints U+0001 through U+10FFFF are allowed.
31
32 Unicode normalization or any other transformation is never performed
33 on any strings (string values or object keys). When checking for
34 equivalence of strings or object keys, the comparison is performed
35 byte by byte between the original UTF-8 representations of the
36 strings.
37
38 Numbers
39 =======
40
41 Real vs. Integer
42 ----------------
43
44 JSON makes no distinction between real and integer numbers; Jansson
45 does. Real numbers are mapped to the ``double`` type and integers to
46 the ``json_int_t`` type, which is a typedef of ``long long`` or
47 ``long``, depending on whether ``long long`` is supported by your
48 compiler or not.
49
50 A JSON number is considered to be a real number if its lexical
51 representation includes one of ``e``, ``E``, or ``.``; regardless if
52 its actual numeric value is a true integer (e.g., all of ``1E6``,
53 ``3.0``, ``400E-2``, and ``3.14E3`` are mathematical integers, but
54 will be treated as real values).
55
56 All other JSON numbers are considered integers.
57
58 When encoding to JSON, real values are always represented
59 with a fractional part; e.g., the ``double`` value 3.0 will be
60 represented in JSON as ``3.0``, not ``3``.
61
62 Overflow, Underflow & Precision
63 -------------------------------
64
65 Real numbers whose absolute values are too small to be represented in
66 a C ``double`` will be silently estimated with 0.0. Thus, depending on
67 platform, JSON numbers very close to zero such as 1E-999 may result in
68 0.0.
69
70 Real numbers whose absolute values are too large to be represented in
71 a C ``double`` will result in an overflow error (a JSON decoding
72 error). Thus, depending on platform, JSON numbers like 1E+999 or
73 -1E+999 may result in a parsing error.
74
75 Likewise, integer numbers whose absolute values are too large to be
76 represented in the ``json_int_t`` type (see above) will result in an
77 overflow error (a JSON decoding error). Thus, depending on platform,
78 JSON numbers like 1000000000000000 may result in parsing error.
79
80 Parsing JSON real numbers may result in a loss of precision. As long
81 as overflow does not occur (i.e. a total loss of precision), the
82 rounded approximate value is silently used. Thus the JSON number
83 1.000000000000000005 may, depending on platform, result in the
84 ``double`` value 1.0.
85
86 Signed zeros
87 ------------
88
89 JSON makes no statement about what a number means; however Javascript
90 (ECMAscript) does state that +0.0 and -0.0 must be treated as being
91 distinct values, i.e. -0.0 |not-equal| 0.0. Jansson relies on the
92 underlying floating point library in the C environment in which it is
93 compiled. Therefore it is platform-dependent whether 0.0 and -0.0 will
94 be distinct values. Most platforms that use the IEEE 754
95 floating-point standard will support signed zeros.
96
97 Note that this only applies to floating-point; neither JSON, C, or
98 IEEE support the concept of signed integer zeros.
99
100 .. |not-equal| unicode:: U+2260
101
102 Types
103 -----
104
105 No support is provided in Jansson for any C numeric types other than
106 ``json_int_t`` and ``double``. This excludes things such as unsigned
107 types, ``long double``, etc. Obviously, shorter types like ``short``,
108 ``int``, ``long`` (if ``json_int_t`` is ``long long``) and ``float``
109 are implicitly handled via the ordinary C type coercion rules (subject
110 to overflow semantics). Also, no support or hooks are provided for any
111 supplemental "bignum" type add-on packages.