Overriding C library’s allocations

[jade laurel]

If I’m creating pure Zig bindings for a C library, and that library exposes preprocessor defines wrapping malloc, calloc, realloc, and free, how would I go about injecting Zig allocation functions?

[spark charm]

Exposes how? Are they replaceable?

[jade laurel]

Yes, they’re defined in such a way that you can define them yourself prior to including the library’s header file.

[spark charm]

Do they have a void* user data argument?

[jade laurel]

They’re defined like so

#ifndef RL_MALLOC
    #define RL_MALLOC(sz)       malloc(sz)
#endif
#ifndef RL_CALLOC
    #define RL_CALLOC(n,sz)     calloc(n,sz)
#endif
#ifndef RL_REALLOC
    #define RL_REALLOC(ptr,sz)  realloc(ptr,sz)
#endif
#ifndef RL_FREE
    #define RL_FREE(ptr)        free(ptr)
#endif

[spark charm]

OK, you can replace them, but you won't be able to decide on which allocator to use in runtime, only in compile time.

[jade laurel]

That makes sense, but how would I go about replacing these? That’s where I’m struggling to connect the dots.

[spark charm]

You have to:

• inject through another macro or some other way the declarations of your allocator functions into the C code
• pass compilation flags set the macros (through -DRL_MALLOC=x)
• define the functions in Zig with the C calling convention

[jade laurel]

I think I need to do a combination of the last 2 bullet points. I’m compiling the C library in build.zig.

[spark charm]

I believe you have to do all of them unfortunately.

[somber raven]

write a wrapper header

that takes care of the first two points

[jade laurel]

I’m wondering if I need to create a separate static library in Zig land that exports some allocation functions. Then I would link that to the C library so it “sees” them

[somber raven]

sure, or you can just export them in your executable

[jade laurel]

That sounds preferable

[somber raven]

you'll still need the wrapper header either way tho, to declare the functions you're defining in zig, and to define the macros for configuring the library

tbh tho, it's normally better to do this integration the other way around - use std.heap.c_allocator in your Zig program, and let your C dependencies just call malloc like normal

[jade laurel]

I was hoping to achieve Zig’s semantics of passing the allocator to functions that allocate memory, but it doesn’t sound like that’s possible. Not Zig’s fault, just a limitation of the C library

[somber raven]

yea

some can do it

but not this one by the looks of it

and even with the ones that can, it's typically much less useful than in zig

[jade laurel]

I got inspired by the Zig SDL3 bindings

So in using std.heap.c_allocator there wouldn’t be any interaction between the C library’s allocations and the user of the Zig bindings using c_allocator?

I wouldn’t think there would be

[somber raven]

wdym by "interaction"?

[jade laurel]

Like the C library wouldn’t somehow be tying into usage of c_allocator

[somber raven]

i mean they're both calling malloc

i don't really understand what you mean by "tying into the usage"

[jade laurel]

I’m not doing a good job articulating - I think I understand what you’re saying though

It’s just good practice when using a C library that uses malloc, to also use c_allocator in the calling Zig program

[somber raven]

yeah, reduces memory usage and heap fragmentation

because malloc can manage all the pages, rather than two different allocators managing their own pages without talking to each other

[jade laurel]

I think that’s what I was gesturing towards by “interacting” and “tying”

Even though they’re not actually talking to each other

As you can tell, I muddy the waters a lot 😁 thanks for the great explanation