| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
https://bugzilla.gnome.org/show_bug.cgi?id=615799
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
|
| |
|
|
|
|
|
|
| |
We switched everything to 64 bit integers but then I forgot to
enable the support for actually making the tokenizer store the
parsed integers into a 64 bit value.
Bad Emmanuele, no cookie for you.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
JsonScanner was forked from GScanner in order to support the
JSON-specific Unicode escaping.
JsonScanner now intercepts the \u escape character and, if it
is followed by a hexadecimal value, it will retrieve the
Unicode character encoded in the following 4 values and insert
the character itself in the buffer.
This allows full compatibility with JSON.
|
| |
|
|
|
|
|
| |
Use a closure instead of (*eugh*) an array of gpointers and casting
to void*.
Also, use the Slice allocator for the ScannerKey structs.
|
| |
|
|
|
| |
Rename all the API and the data types to the Json namespace, so we can
use the internal copy instead of GScanner.
|
| | |
|
|
|
Instead of writing our tokenizer we can fork GScanner and make a
specialized version for JSON (as per RFC), luckily the licenses
are compatible (LGPLv2.1 with "any later" clause).
GScanner does not support Unicode "\uNNNN" escaping and we need to
ensure UTF-8 strings as well.
The API will mostly be the same, but the generic bits not used by
JsonParser will be hidden: this is, after all, a specialized
tokenizer.
|
