> This will be used to align the data. For some reason, our computers are much better at dealing with data that is aligned at 8 bytes. This means that the start of each new allocation has to be at a multiple of 8 bytes.
Casting a pointer which is not aligned to its natural alignment has undefined behavior in C. It's not just an issue of unaligned accesses being slow; in practice, your program might also crash or access unexpected data on real platforms with real compiler implementations.
Also, your code is prone to overflow when you add data, used, alignment and size.
And finally, the realloc function could be reworked to do nothing if new_size is <= old_size.
- The macros doing arithmetic (KiB, MIN etc) don't put their arguments in parentheses, that is very dangerous.
- The code assumes that int and i32 are the same size.
- Don't cast the return value of malloc(). Please Google this.
I appreciated the use of structs by value, that's a nice design.
I agree there's a risk of overflow in the arithmetic around sizes/alignment, but with a 64-bit `usize` that should be mostly theoretical.
Casting a pointer which is not aligned to its natural alignment has undefined behavior in C. It's not just an issue of unaligned accesses being slow; in practice, your program might also crash or access unexpected data on real platforms with real compiler implementations.