Skip to content

Conversation

@f1nalspace
Copy link

I added a simple, but powerful custom allocator scheme to your library, that fully replaces all malloc/free calls - but still uses malloc as its default allocator, when not overridden by the user.

In addition i added json_write_minified_ex() and json_write_pretty_ex(), to support a custom allocator in there as well.

I would really appreciate it, if you could merge that into your master branch. Thanks!

json_free_func_t *free;
/* Custom user data pointer. */
void *user_data;
/* Padding to align struct. */
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need this padding?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alignment padding is always a good idea.
Sure you can leave that out, but i always do this. Its a habit, i am a low-level programmer and i care about CPU cache alignment a lot.

};

json_weak struct json_allocator_s json_create_allocator(struct json_allocator_s *custom_allocator) {
if (json_null == custom_allocator || json_null == custom_allocator->alloc || json_null == custom_allocator->free) {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this - so if you mess up one of the allocators it just falls back to the default allocator?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, you don't want an allocator that is half-baked / mixed. Either you specify it or not.

json_weak struct json_value_s *
json_parse_ex(const void *src, size_t src_size, size_t flags_bitset,
void *(*alloc_func_ptr)(void *, size_t), void *user_data,
struct json_allocator_s *allocator,
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What gives me pause with this is that this can imply that we would call free in this function, which we definitely will not. I think I'd rather keep the old API and just explicitly add another argument for free_func_ptr on the write functions that need it.

Copy link
Author

@f1nalspace f1nalspace Jan 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added that which makes the most sense for me. Also i really hate such long prototypes defined directly in an argument. If you could at least make a typedef for that, then it would be much cleaner. But you can do whatever you want. I wrap your library anyway, which i do for all external libraries i use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants