Recent changes to feature-requests

#9 Thread Safety Issue due to "ep"

Marcos Kirsch — Wed, 13 Jan 2016 20:15:47 -0000

In order to maintain source compatibility, the extra ep parameter could have a defualt value of NULL, and the implementaiton can treat NULL ep to mean "use the non-thread-safe static".

If this is not possible, new thread safe flavors of the functions that touch ep would need to be introduced with the extra parameter.

I think making cJSON thread safe in 2016 should be high priority.

Provide support for 64-bit integers

Marcos Kirsch — Fri, 24 Jul 2015 16:16:11 -0000

I'd like the ability to parse/store integers larger than an int. On most platforms int is 32-bits. So any positive value larger than 31 bits does not work without hacks/workarounds. This is a common use case for me since I'm storing Product IDs which are typically 32 bit long unsigned values.

The easiest is to change the struct:

typedef struct cJSON {
struct cJSON next,prev;
struct cJSON child;
int type;
char valuestring;
long long valueint;
double valuedouble;
char *string;
} cJSON;

But of course code around it and tests would need to be updated. I assume the change needs to be opt-in so a typedef surrounded by #define needs to be created.

Add a method to list the keys in an object.

Dustin Oprea — Thu, 25 Apr 2013 19:24:38 -0000

Something similar to the following:

static bool get_json_object_keys(cJSON *object, vector<string> *v)
{
if(object == NULL)
return false;

if(object->type != cJSON_Object)
return false;

v->clear();

cJSON *c = object->child;
while(c)
{
v->push_back(c->string);
c = c->next;
}

return true;
}

Thread Safety Issue due to "ep"

asif — Wed, 17 Apr 2013 07:39:35 -0000

cJSON contains a static global "ep" pointer that could be a problem for threads safety. I am not sure whether the "thread safety" has been verified for cJSON, but "ep" is one potential problem.

To fix this, one way is to pass "ep" as parameter to the functions where it is being modified.

UTF-8 encoding: NUL character not supported

Jerome Lang — Tue, 29 Nov 2011 15:58:15 -0000

This might be not very common, but I need to encode (and decode) strings including the control character NUL in the middle of a string (not as string terminator). I would expect that a character byte with a binary value 0 is encoded to \u0000 like a binary value 1 is encoded to \u0001.
This doesn’t work since the parser uses strlen() to determine the string lengths... maybe a second cJSON_CreateString() function could be created which takes the length as argument. This might speed up code due to missing strlen() calls.

Trailing Commas do nothing instead of error

Mike Kasprzak — Tue, 25 Oct 2011 21:02:58 -0000

I realize it's against the JSON spec, but I'd like to suggest making commas that follow an array or object do nothing instead of raise an error.

Personally, I find in C/C++ when I'm hardcoding arrays, I leave a trailing comma. An example:

char* Data[] = {
"Some text",
"Some other text",
};

This lets me re-arrange the data (copy+paste) without having to update the ends of line. I just wish C++ constructor initializer lists let me do this too. ;)

This works espcially nicely with line comments (//), removing items with a keystroke (see other feature request).

Anyways, that's my suggestion(s). Thanks for making such a great library.

C/C++ style comments

Mike Kasprzak — Tue, 25 Oct 2011 20:54:39 -0000

Support for C and C++ style comments.

// C++ Style, a double slash, then all characters until a newline character (0x13 or 0x10) are ignored
/* C Style, all characters until the closing pattern are ignored */

I've been doing a bunch of by-hand editing of files, and this is 1 of 2 items I would love to see.

PS: Great work on the library. Thanks!

Better warnings when there are syntax erros in input

Andrew Fabbro — Thu, 02 Dec 2010 18:59:30 -0000

I'm working on an app that in many cases uses a config file which is hand-generated. cJSON_Parse appears to return NULL if the parse isn't successful, but that's the only indication/output. There's no way to tell the user where in the JSON the error is or what kind of error it is. Setting something or returning something that states the error was at line X (or character X) would be a great help.

Support compilation under -ansi limitations?

Chris Nigbur — Wed, 12 May 2010 15:58:46 -0000

Are there any thoughts to making cJSON compile under the strict -ansi options? The main issue is the comment style used is not supported under -ansi.

overflow warning

Anonymous — Sun, 31 Jan 2010 21:04:31 -0000

When I compile I get:
cJSON.c:135: warning: overflow in implicit constant conversion

Changing the char firstByteMark to an unsigned char, resolves the compilation warning.

Attached simple patch.