4 ms·
The idea that if you provide an alternative to free which requires the originally allocated alignment and size then users of it will provide the correct values
by nuc1e0n 4y ago
The idea that if you provide an alternative to free which requires the originally allocated alignment and size then users of it will provide the correct values is very naive. Rust's allocator interface looks very similar to malloc and free. I can guess which functions the main implementation of that calls.
I think a big flaw with malloc is that the returned values are memory addresses and not just handles. That means objects can't be moved around in memory once allocated. There's also no notion of types with malloc, just memory sizes in bytes. That makes heap fragmentation more of a problem. Plus if you have an allocated object containing a pointer to another allocated object there's no easy way to free all the memory allocated by the entire structure.
Finally, I think better support for putting data on the stack instead of the heap from the beginnings of unix with alloca would also have prevented memory leaks somewhat.
- pjmlp 4y agoYou can fake handles by using additional memory on the allocated block, but it better be there for free(). Moving them around isn't a big problem, there are some allocators that ping back on the MMU with double indirection. I never understood why C never got an higher level memory allocation API, after all, it isn't as if the 10 years of systems programming languages that preceeded it didn't had already NEW(type) as primitive. The problem with alloca() is that C isn't Ada, so instead of an allocation error if the stack isn't big enough, you get a corrupted stack.
- nuc1e0n 4y agoMaybe the 'stack' could be a linked list in the heap as well, then there wouldn't be a practical limit to its size. Alloca being not great is an implementation issue rather than an issue with the interface.