Feature: Custom Memory Allocator

[suhasravi7]

Summary

Adds custom memory allocator support to the JOSE library, allowing applications to override default malloc/realloc/free functions for specialized memory management needs.

Changes

• Added jose_set_alloc() and jose_get_alloc() API functions
• Added comprehensive test suite (api_mem.c)
• Updated build system integration

Use Cases

• Memory debugging and tracking
• Custom memory pools
• Secure memory allocation
• Cross-DLL memory management

Testing

meson test -C build api_mem

All tests pass, validating functionality across different usage scenarios.

[sarroutbi]

The size_t type is not a built-in keyword in C; it's defined in standard library headers like <stdlib.h>. Please, fix include/jose/cfg.h to include the corresponding one

[suhasravi7]

The size_t type is not a built-in keyword in C; it's defined in standard library headers like <stdlib.h>. Please, fix include/jose/cfg.h to include the corresponding one

Updated the PR

[sarroutbi]

Hello @suhasravi7 . Thanks for the patch.

I guess it is not as easy as I thought ... could you please merge next change to your branch and incorporate it to the PR to check if compilation errors are fixed?

[sarroutbi]

Hello @suhasravi7 : Could you please justify why this should be merged? We don't see a clear requirement to change memory allocators, and we find some security constraints on including it ... which architecture, software, product, ... justifies this change? CC @sergio-correia

[suhasravi7]

Hello @suhasravi7 : Could you please justify why this should be merged? We don't see a clear requirement to change memory allocators, and we find some security constraints on including it ... which architecture, software, product, ... justifies this change? CC @sergio-correia

Thank you for raising these concerns @sarroutbi.

The motivation for introducing a custom memory allocator support in JOSE stems from our deployment environment, where we utilize an H2O proxy(https://github.com/h2o/h2o). H2O internally pre-allocates and manages memory blocks to optimize performance and reduce allocation overhead, especially under high concurrency. To align with this architecture and fully leverage these performance benefits, we require JOSE to support custom memory allocators.

By enabling JOSE to use externally managed allocators, we can maintain consistent memory management strategies across our stack. This approach offers measurable improvements in allocation speed and reduces fragmentation, compared to standard malloc/calloc routines. Additionally, it allows for tighter control over memory usage, which is critical in high-performance and resource-constrained environments.

Regarding security, the implementation ensures that allocator hooks are strictly opt-in and can be sandboxed or audited according to deployment requirements. The change is modular and does not impact default behavior unless explicitly configured.

[vikaspushkar]

should the api jose_cfg_set_alloc enforce consistency in the passed parameters. either all should be NULL or Non-NULL. a combination of NULL and Non Null paramters could lead to mis management of the allocated memory here?

[suhasravi7]

should the api jose_cfg_set_alloc enforce consistency in the passed parameters. either all should be NULL or Non-NULL. a combination of NULL and Non Null paramters could lead to mis management of the allocated memory here?

@vikaspushkar updated the pr to handle this case

[sarroutbi]

Hello @suhasravi7 : Could you please justify why this should be merged? We don't see a clear requirement to change memory allocators, and we find some security constraints on including it ... which architecture, software, product, ... justifies this change? CC @sergio-correia

Thank you for raising these concerns @sarroutbi.

The motivation for introducing a custom memory allocator support in JOSE stems from our deployment environment, where we utilize an H2O proxy(https://github.com/h2o/h2o). H2O internally pre-allocates and manages memory blocks to optimize performance and reduce allocation overhead, especially under high concurrency. To align with this architecture and fully leverage these performance benefits, we require JOSE to support custom memory allocators.

By enabling JOSE to use externally managed allocators, we can maintain consistent memory management strategies across our stack. This approach offers measurable improvements in allocation speed and reduces fragmentation, compared to standard malloc/calloc routines. Additionally, it allows for tighter control over memory usage, which is critical in high-performance and resource-constrained environments.

Regarding security, the implementation ensures that allocator hooks are strictly opt-in and can be sandboxed or audited according to deployment requirements. The change is modular and does not impact default behavior unless explicitly configured.

Thanks for clarifying. Changes LGTM. Let's wait for a double opinion regarding this and we can merge it

[sarroutbi]

LGTM

[simo5]

Just a comment, but I think this code can be made more compact and efficient.

[simo5]

LGTM