JSON patch is a bit more clear on how some array operations should be
handled. Unfortunately, handling them on a case-by-case is a bit tricky
because it's difficult to satisfy properly an 'add' operating with a 'move'
operation and the basic json_pointer_set().
With json_pointer_set{f}() we use json_object_array_put_idx() to insert a
value at a certain index.
With JSON patch:
* for the 'add' operation, we need to insert a value at a given index,
which means shifting existing values by one to the right
- also, we cannot allow values to be inserted/added outside the bounds of
the array
* a 'move' operation, is described as a 'remove' and then an 'add';
for arrays this complicates things, because when we want to a move a
value within the array, we have to remove it first (during which the size
of the array is reduced by one); when the size of the array is reduced by
one, we can't add it to the last position in the array (before the
remove)
The only sane method to handle this (after a few considerations) is to
provide a callback to the function that does the final put/insert into
the array. That way, we can do some final checks where these are needed to
handle each corner-case.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
For JSON patch, we require that we get access to the parent of a JSON
object as well in order to do some operations via the API.
For example, given the object:
{
"foo": "bar",
"array", [ 1, 2, 3]
}
Using JSON pointer with the path
* '/foo' will return 'bar' of type string
* '/array/0' will return '1', of type integer
The problem is, that if we do 'json_object_put()' on any of the objects
above, this will not detach them from the parent, because there is no
information back to the parent.
One way to fix this, is to introduce links back to the parent, and have
these links be made by 'json_object_array_{put,insert}_idx()' and
'json_object_object_add{_ex}()'[1].
[1] For json_object_object_add_ex() we would need to de-constify the second
parameter, as we need to change it's internal state when being added to a
parent object. It may break some applications, but who knows.
But, since this information is needed mostly for JSON patch, another way to
address this, is to also retrieve the parent of an object via JSON pointer
and use json_object_object_del() and json_object_array_del_idx() on the
object's parent.
Signed-off-by: Alexandru Ardelean <ardeleanalex@gmail.com>
This causes previously failing strings like "123-456" to return a valid json_object with the appropriate value. If you care about the trailing content, call json_tokener_parse_ex() and check the parse end point with json_tokener_get_parse_end().
Remove all of the temporary defines, structures, old compat fuctions, extra fields, etc... that were needed during the conversion to a split set of json_object_* structures.
The default is now that string data is stored inline at the end of json_object, though to allow for json_object_set_string() to set a _longer_ string, we still need to allow for the possibility of a separate char * pointer.
All json types have been split out now, next step it cleanup.
The current changes split out _only_ json_type_object, and thus have a number of hacks
to allow the code to continue to build and work.
Originally mentioned in issue #535.
When complete, this will probably invalidate #552.
This is likely to cause notable conflicts in any other significant un-merged
changes, such as PR#620.
- there is no need for _ref_count to be uint_fast32_t (the compiler
might decide to use a 64-bit int). make it uint32_t instead.
- reorder the 32-bit integer fields (o_type and _ref_count) so that
there is no wasted 4-byte gap after each of them.
smalls strings inside json_objects had a high overhead because dynamic
memory allocation was needed for each of them. This also meant that the
pointer needed to be updated. This is now changed so that small strings
can directly be stored inside the json_object. Note that on the regular
64 bit machines a pointer takes 8 bytes. So even without increasing
memory, we could store string up to 7 bytes directly inside the object.
The max size is configurable. I have selected up to 31 bytes (which
means a buffer of 32 including the NUL byte). This brings a 24-bytes
memory overhead, but I consider that still useful because the memory
allocator usually also has quite some overhead (16 bytes) for
dyn alloced memory blocks. In any case, the max buffer size can be
tweaked via #define.
There are now three options: JSON_C_TO_STRING_SPACED, JSON_C_TO_STRING_PLAIN and JSON_C_TO_STRING_PRETTY.
This also add a json_object_to_file_ext() that takes the same flags.
Existing output of json_object_to_json_string() is unchanged, and uses JSON_C_TO_STRING_SPACED.
Thanks fo Grant Edwards for the initial patches.
In building large systems, there are often clashes over the
preferred base type to use for bool/boolean. At least one
experience has been with a 3rd party proprietary library which
can not be changed. In that case, boolean was a synonym for
unsigned char and used widely in packed structures.
Added parse_null test. This does not change anything with how the parser handles \u0000 or null characters
This commit is addapted from one by Adomas Paltanavičius <adomas@leanholding.com>
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@63 327403b1-1117-474d-bef2-5cb71233fd97
omit the range check during parsing since we already have the checks when
accessing the value. There is no longer a json_type_int64, only json_type_int.
Fix some problems with parsing 0 and -0 values, and add a couple of tests.
Fix some minor compile issues on HPUX environments.
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@60 327403b1-1117-474d-bef2-5cb71233fd97
json_object_get_int64. Binary compatibility preserved.
Eric Haszlakiewicz, EHASZLA at transunion com
Rui Miguel Silva Seabra, rms at 1407 dot org
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@56 327403b1-1117-474d-bef2-5cb71233fd97
* Add casts from void* to type of assignment when using malloc
* Add #ifdef __cplusplus guards to all of the headers
* Add typedefs for json_object, json_tokener, array_list, printbuf, lh_table
Michael Clark, <michael@metaparadigm.com>
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@33 327403b1-1117-474d-bef2-5cb71233fd97
* Add ifdef C++ extern "C" to headers
* Use simpler definition of min and max in bits.h
Larry Lansing, llansing at fuzzynerd dot com
* Remove automake 1.6 requirement
* Move autogen commands into autogen.sh. Update README
* Remove error pointer special case for Windows
* Change license from LGPL to MIT
Michael Clark <michael@metaparadigm.com>
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@10 327403b1-1117-474d-bef2-5cb71233fd97
Added a Win32/Win64 compliant implementation of vasprintf
* debug.c - C. Watford (christopher dot watford at gmail dot com)
Removed usage of vsyslog on Win32/Win64 systems, needs to be handled
by a configure script
* json_object.c - C. Watford (christopher dot watford at gmail dot com)
Added scope operator to wrap usage of json_object_object_foreach, this
needs to be rethought to be more ANSI C friendly
* json_object.h - C. Watford (christopher dot watford at gmail dot com)
Added Microsoft C friendly version of json_object_object_foreach
* json_tokener.c - C. Watford (christopher dot watford at gmail dot com)
Added a Win32/Win64 compliant implementation of strndup
* json_util.c - C. Watford (christopher dot watford at gmail dot com)
Added cast and mask to suffice size_t v. unsigned int conversion
correctness
* json_tokener.c - sign reversal issue on error info for nested object parse
spotted by Johan Bj�rklund (johbjo09 at kth.se)
* json_object.c - escape " in json_escape_str
* Change to automake and libtool to build shared and static library
Michael Clark <michael@metaparadigm.com>
git-svn-id: http://svn.metaparadigm.com/svn/json-c/trunk@4 327403b1-1117-474d-bef2-5cb71233fd97
Eric Hawicz
Alexandru Ardelean
dota17
Ramiro Polla
Björn Esser
Rainer Gerhards
Keith Derrick
Jehiah Czebotar
ehaszla
Michael Clark