Provide a way to free memory with the provided size

Provide a way to free memory with the provided size

[inlife]

Hey @Sucuturdean

An interesting albeit unusual suggestion! Are there any live examples of this implementation in other libraries?

Also, zpl supports multiple different allocation strategies, and yes, the standard heap allocation is one of them. And those strategies allow a lot of flexibility to the end user.

Hello @inlife

I have taken inspiration from the standard library that zig uses. In that std, you provide the size to the free function because in that language allocating returns a slice (which is a struct containing a pointer and size). In c there isn't a concept of slice, but I thought that since that is slightly faster, someone might want to use that version. I am also aware that this library is trying to be simple and a function like this might not be good for it (that's why I opened an issue first).

Just realised while writing this another reason for this. If someone already keeps tabs on the size of their allocated object, then why duplicate that variable when the user can simply pass it to the free function?

[inlife]

Let's also wait for an answer from @zaklaus, he should be back in a couple of days, and decide then.

[zpl-zak]

Hi, thank you for the proposal!

While I understand that such a change could be helpful in some instances, I'm unfortunately unable to accept it as it doesn't fit within this library.

Let's first explore how zpl deals with memory allocation and what restrictions or requirements the library currently imposes on users to understand better why this enhancement wouldn't work in zpl:

ZPL offers multiple memory allocation strategies, all relying on a unified API to allocate, resize, and free memory; each allocation strategy has its own rules and restrictions.

The heap allocator is the simplest one, as it solely depends on your runtime's memory allocator to manage memory. Therefore it's wholly reliant on your system. Providing the size to the free method wouldn't benefit here as it would be unused internally.

The arena/linear allocator disallows us to free allocated blobs since we don't track nor partition the memory. Instead, it offers memory snapshot capturing to imitate temporary memory allocation regions and those already "cache" the used memory and use it if we want to restore a snapshot. The size argument wouldn't apply here since the free method is incompatible with this allocator.

The pool allocator uses a linked list of equally allocated blobs to manage the memory. Since we know the blob size beforehand, the size argument is not required when we free memory.

The stack allocator prepends the allocated memory with a header that stores the allocated size so that when we call the free method, we already know the size we need to free. Therefore the size argument isn't required here.

The scratch memory (ring buffer) allocator does not allow us to free individual allocations (since it wraps a fixed-size block of memory). Therefore the size argument isn't required as the free method isn't compatible here.

In conclusion, each allocation strategy either doesn't directly support the ability to free memory, or we already know the size we need to de-allocate beforehand.

Let me know if you have any questions or ideas, and I'd gladly discuss them!

[zpl-zak]

I will close this issue now, but if you have other suggestions, feel free to re-open it!