Need public API to free returned strings (e.g. cJSON_Print) about cjson HOT 13 CLOSED

You should implement cJSON_Hooks and discourage them from doing the same.

from cjson.

I propose adding cJSON_Hooks as optional parameter to all the functions that are doing frees/allocations. That would be part of the breaking changes for 1.0.0

from cjson.

What is passed will be a pointer to cJSON_Hooks and if null, regular malloc and free will be used.

from cjson.

Nice.

from cjson.

While you're there, it might be wise to remove unbuffered printing entirely, especially since you have ensure() working nicely now :)

from cjson.

I would suggest rename cJSON_Delete to cJSON_DeleteObject and create a new API cJSON_DeleteBuffer which frees the print buffer using hook. Let me know I can create patch for that.

from cjson.

No. By allowing the user to pass in a pointer to an instance of cJSON_Hooks, the user of the library knows which allocator was used for allocating the printbuffer, so no special function is required for that, just use the deallocator that fits the allocator you gave to cJSON for printing.

from cjson.

Is there currently any way using cJSON_Hooks to pass along another void pointer that could go to the allocator? I can't see a way. This would be necessary to do something like using a memory pool allocator? Obviously this would require major upheaval to the api, but seems if this is going to happen, now would be the time. Is there any interest in looking at that now, or would it be too invasive to make sense?

from cjson.

This sounds feasible for v2. My idea was to have an extended cJSON_Hooks struct that get's passed in (as pointer) to every function that allocates memory. If left NULL, defaults would be used. That new cJSON_Hooks is also supposed to have a pointer to a realloc function (optional) and may also contain the error pointer (or rather error position).

Allocator functions that take a void pointer could be added as separate fields to this struct (or be the default, not sure).

I will definitely put this feature on the list.

from cjson.

Yes.. this approach makes sense... the other way to do it.. which probably has value, is to include a concept of a "parent" object, and work the api to pull that void pointer from the parent object. Having access to the parent to be able to walk back up to the root json may also have other unexpected advantages. Anyway all food for thought. We are not using anything like this now, but have at least talked about how it would be useful.

from cjson.

Interesting idea. But I don't think this works for allocators because any object can be detached from the tree and become it's own root at any time.

from cjson.

I added cJSON_malloc and cJSON_free on the develop branch. Since version 2 is still way ahead I decided to just add simple wrappers that call the internal functions. They will be removed again in version 2.

This is still quite prone to race conditions though.

from cjson.

cJSON_malloc and cJSON_free are now available with version 1.5.0

from cjson.