alt Hacker NewsMore obvious problems with the code as shown:
- 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.
> The code assumes that int and i32 are the same size.
Tbf this is extreme nitpicking. It's very unlikely that the code will ever be built on a compiler where int is not 32 bits. Replacing the sizeof(int) with sizeof(i32) is better of course, and tbh it looks like an oversight, not intentional.
> Don't cast the return value of malloc(). Please Google this.
This is required when the code should also build in C++ mode (which some weirdos seem to prefer for "improved type safety") - in any case, the explicit cast is also entirely valid C code, so not wrong just redundant.
> The macros doing arithmetic (KiB, MIN etc) don't put their arguments in parentheses, that is very dangerous.
Agreed.
I would add though:
> Don't typedef C primitive types to your own shortcuts (like int32_t => i32), at least not when those typedefs leak into the public API, because then your i32 may collide with another library's i32.