Please be aware that pointer arithmetic is not defined on void * pointers, although many compilers allow it. You had better use char * for "data".<p>Also, your code is prone to overflow when you add data, used, alignment and size.<p>And finally, the realloc function could be reworked to do nothing if new_size is <= old_size.
More obvious problems with the code as shown:<p>- The macros doing arithmetic (KiB, MIN etc) don't put their arguments in parentheses, that is very dangerous.<p>- The code assumes that int and i32 are the same size.<p>- Don't cast the return value of malloc(). Please Google this.<p>I appreciated the use of structs by value, that's a nice design.<p>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.
> 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.<p>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.
Why redefine the stdints?