| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
It's pointless to add the '-test' suffix to files under the tests/ directory.
|
| |
|
|
|
| |
While verifying Array.foreach() we should also verify that the list we
are iterating on is the same returned by the get_elements() method.
|
| |
|
|
| |
Do not include json-types.h, use the correct global include.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The JSON RFC does not specify the size of the integer type, thus
implicitly falling back to machine-size.
This would all be fine and dandy if some demented Web Developer (and
I use the term "developer" *very much* loosely) did not decide to
use integers to store unique identifiers for objects; obviously, you
can't have more than 2^32-1 status messages in a database with
millions of users who update their status multiple times per day.
Right, Twitter?
Anyway, some languages do a type auto-promotion from Integer to
Long, thus pushing the limit of allowed positive values -- until the
next integer overflow, that is. C, and GLib, do not do that
transparently for us so we need to:
- always use gint64 when parsing a JSON data stream using
JsonScanner
- move all the Node, Object and Array APIs to gint64
- auto-promote G_TYPE_INT to G_TYPE_INT64 when setting
a GValue manually
- auto-promote and auto-demote G_TYPE_INT properties when
(de)serializing GObjects.
The GLib types used internally by JSON-GLib are, thus:
integer -> G_TYPE_INT64
boolean -> G_TYPE_BOOLEAN
float -> G_TYPE_DOUBLE
string -> G_TYPE_STRING
|
| |
|
|
|
|
| |
Similarly to commit 3057a172 for JsonObject, the newly added
json_array_foreach_element() iterates over a JSON array data
type.
|
| |
|
|
|
|
| |
Remove the json_array_remove_element() call from the add-element test unit
and set up a separate test case for the element removal. This keeps the
test cases clean.
|
|
|
This simple unit will test the JsonArray API, as part of the coverage
test for the JSON-GLib types.
|
