git-svn-id: http://svn.code.sf.net/p/cjson/code@42 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@41 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@40 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@39 e3330c51-1366-4df0-8b21-3ccf24e3d50e

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

git-svn-id: http://svn.code.sf.net/p/cjson/code@36 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@35 e3330c51-1366-4df0-8b21-3ccf24e3d50e

(changed all C++ // comments to C /* */ comments).



git-svn-id: http://svn.code.sf.net/p/cjson/code@34 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@33 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@32 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@31 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@30 e3330c51-1366-4df0-8b21-3ccf24e3d50e

Many thanks to an anonymous submitter for this fix!!



git-svn-id: http://svn.code.sf.net/p/cjson/code@29 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@28 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@27 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

declare variable first, so we're proper c ;)


git-svn-id: http://svn.code.sf.net/p/cjson/code@25 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@24 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@23 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@22 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@21 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

Unformatted output. :)



git-svn-id: http://svn.code.sf.net/p/cjson/code@19 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@18 e3330c51-1366-4df0-8b21-3ccf24e3d50e

fix bug 2895595 from jshvrsn whereby values outside of INT_MIN/INT_MAX range are printed incorrectly as ints.



git-svn-id: http://svn.code.sf.net/p/cjson/code@17 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@16 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@15 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@14 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

git-svn-id: http://svn.code.sf.net/p/cjson/code@11 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

git-svn-id: http://svn.code.sf.net/p/cjson/code@9 e3330c51-1366-4df0-8b21-3ccf24e3d50e

handling of string length was incorrect.



git-svn-id: http://svn.code.sf.net/p/cjson/code@8 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@7 e3330c51-1366-4df0-8b21-3ccf24e3d50e

also missed the casts on realloc()



git-svn-id: http://svn.code.sf.net/p/cjson/code@6 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

git-svn-id: http://svn.code.sf.net/p/cjson/code@4 e3330c51-1366-4df0-8b21-3ccf24e3d50e

git-svn-id: http://svn.code.sf.net/p/cjson/code@3 e3330c51-1366-4df0-8b21-3ccf24e3d50e