21–30 of 60 posts
Earlier quoted context omitted.
How do you think we should be dealing with memory allocation instead?
addr = getrandom(8); mem = mmap(addr, len, PROT_RWX, MAP_FIXED|MAP_ANON, -1, 0);
Is this missing code? I can’t find a definition of Heap anywhere.
Is this missing code? I can’t find a definition of Heap anywhere.
https://github.com/thi-ng/tinyalloc/blob/master/tinyalloc.c#...
If I read the code correctly, ta_free() is O(n), whereby n is a number of allocated blocks. That's not very good. PS. Also the block alignment is aligning the wrong thing. It should be aligning the start of the public (returned) part, not the block size and that's done by padding Block struct as required (if required)... and not to the hardcoded 8 bytes. Otherwise you'll get SIGBUS on RISC boxes. PPS. At the risk of…
Basically you can fail memory allocation with a lot of small allocations that aren't using all of a block. This situation bit me when using some C++ code on a Cortex-M class processor where the C++ code ended up creating a bunch of objects with very small allocations in them.
That said, the code is pretty clean and easy to read so its a pretty understandable allocator. Some malloc implementations are so opaque you have to study them for a week to tease out how they work.
Its a nifty tool, but I can't help feeling a little disappointed that we're still having to deal directly with issues such as memory allocation in 2019.
Earlier quoted context omitted.
It is quite possible (and it can be reasonable) to deviate from that rule. For example you could write a wrapper for malloc that only allows dynamic allocation in the initialization phase of your program. This can be useful to allocate memory for opaque-pointer-style types.
There are other ways to get chunks of memory separate from the stack - static uninitialized byte arrays.