You really oughtn't go too far with this, because it's only loose information; as I've said before, cJSON +isn't+ a validating parser. But this might give you enough info to save yourself on some rare occasion ;)
git-svn-id: http://svn.code.sf.net/p/cjson/code@38 e3330c51-1366-4df0-8b21-3ccf24e3d50e
In a certain sense, we shouldn't be seeing them, but this way we at least handle them well.
git-svn-id: http://svn.code.sf.net/p/cjson/code@37 e3330c51-1366-4df0-8b21-3ccf24e3d50e
I might make cJSON_strcasecmp hookable, depending on what feedback i get.
There are now +NO+ #ifdef/#endif WINDOWS clauses, just neat ANSI C.
Also, this DOES NOT represent an efficiency hit for parsing, since the casecmp code is ONLY used for retrieval of object values, which would be after the parse stage.
git-svn-id: http://svn.code.sf.net/p/cjson/code@26 e3330c51-1366-4df0-8b21-3ccf24e3d50e
If you need to add an existing cJSON to a new object, but the existing object
must not be affected by this, use cJSON_AddItemReferenceTo<Array|Object>.
This will make a "reference" to the existing object (which is what you really mean to do),
and allow you to use it with a new object without fear of names being corrupted or things
being deleted.
Think of it like a reference, since that's pretty much what it is.
If you modify the resulting object (i.e. you AddItemReference, then retrieve with GetObjectItem,
and then start adding/replacing) you'll modify the object you pass in (in other words, this
doesn't clone everything, since that would probably end up being wasteful of space), however,
if you add it, and treat it as if it were const, everything will be fine!
git-svn-id: http://svn.code.sf.net/p/cjson/code@20 e3330c51-1366-4df0-8b21-3ccf24e3d50e
Based on an idea from Daniel Harcek; these are designed to allow you to replace entries in an object or array with new
values. The old values get deleted and the new ones are wired into place.
This leads to a structure like this:
cJSON_ReplaceItemInObject(myobject, "spooncount", cJSON_CreateNumber(24));
cJSON +NEVER+ type checks, so it's perfectly legal to replace an object with a string (to cJSON) though it may not be in your schema!
git-svn-id: http://svn.code.sf.net/p/cjson/code@13 e3330c51-1366-4df0-8b21-3ccf24e3d50e
That seemed horribly inefficient to me.
Now we use multiple passes and can test for failure more carefully.
git-svn-id: http://svn.code.sf.net/p/cjson/code@12 e3330c51-1366-4df0-8b21-3ccf24e3d50e
also new errorhandling for memory failure cases. +I HAVE NOT CHECKED THIS FOR ABILITY TO LEAK!+
git-svn-id: http://svn.code.sf.net/p/cjson/code@10 e3330c51-1366-4df0-8b21-3ccf24e3d50e
added strcasecmp->stricmp
added (char*) casts to all mallocs (as reqd by c++)
added skip(value) to cJSON_Parse to allow for whitespace before the actual data
git-svn-id: http://svn.code.sf.net/p/cjson/code@5 e3330c51-1366-4df0-8b21-3ccf24e3d50e
