| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
It's pointless to add the '-test' suffix to files under the tests/ directory.
|
| |
|
|
| |
JsonNode should mimick GValue's API and have macros for easy type checking
|
| |
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
The JsonNode structure has always been meant to be completely
opaque; we indirectly exposed the :type member, but only for
access through the JSON_NODE_TYPE() macro.
Since that macro has become a proxy for the json_node_get_node_type()
function we can safely move everything into a private, uninstalled
header file and let JsonNode be completely opaque to the developer.
|
| |
|
|
|
|
|
| |
Since json_object_add_member() has been deprecated and it's using
a gcc compiler attribute to loudly complain while compiling the
library, we should restore the sanity and use json_object_set_member()
instead.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug 1353 - Copying JSON_NODE_VALUE nodes unreliable at best
When copying a JsonNode to another we do an implicit memcpy using:
*copy = *src
Which works well enough with pointers, but makes a mess out of the
value-based nodes.
We should just copy the type of the original JsonNode and leave the
rest to the switch() block.
In order to catch potential regressions, we also need a more
thorough test unit for the JsonNode copy operation.
|
| |
|
|
| |
Test the GValue API for storing fundamental types into a JsonNode.
|
| |
|
|
|
| |
The test unit copies a NULL JsonNode and checks that the copy and the
original nodes are equivalent.
|
|
|
GLib 2.15 added a new test unit framework to the GLib API. It allows
integrating unit testing into GLib and GObject based libraries and
applications.
It requires a specially crafter Makefile holding a set of declarations,
which must be included into the project own Makefile templates; then
it is possible to drop tests inside a subdirectory, which will be built
after the library or application, and executed upon "make check".
At the moment, there is a simple test for the JsonNode API, with a
single unit for the "null" node type.
|
