So, here is the third attempt at reporting this issue...
Note that your suggested resolution for #3454351 did not solve the problem I described, since the parser simply does not bail out. Hence my conclusion that you did not understand the issue - you did not state that accepting garbage at the end of the JSON is desired behaviour.
Your statement in bug #3566143 "Ending in garbage DOES NOT MAKE IT INVALID JSON." is factually incorrect. The grammar specified in RFC 4627 does not allow for garbage at the end of a json string. Also it states the intention that "JSON is a subset of JavaScript", which obviously contradicts garbage at the end of the string.
You may of course choose to construct your parser in a way that it accepts strings that do not conform to the JSON specification ("A JSON parser MAY accept non-JSON forms or extensions."), but given the history of severe security bugs coming from badly validated data suggests that this might be a not-so-smart approach for garbage.
And since you don't seem to believe that my suggestion was simple, here is a patch attached. Obviously this kills the API compatibility, which could be solved by introducing a new "cJSON_ParseSafe"-Function, but I'll leave it up to you to decide how to deal with that.
patch fixing/extending the cJSON_Parse behaviour.
Patch is great! Honestly didn't spot that I could retrieve the last parsed byte from the cJSON_Parse.
Thanks for solving the problem- will wire this into API tomorrow.
Ace!
cJSON_Parse should have read parse_value.
Fixed, in SVN. You'll want to use cJSON_ParseWithOpts(string,&endptr,1). Or some combination. All the functionality in your patch is in there, with optional usage, without breaking the API, and only two extra compares :D