It is totally fine for C code to make "assumptions about the platform".

I'm not sure where this obsession with non-existing or irrelevant target platforms is coming from that might be theoretically supported by the C standard, but are not relevant in the real world except for niche use cases which the library author might not care about (like some extremely limited embedded CPUs). E.g. not every C library needs to support every target platform just because that target platform has a C compiler, and all code (not just C code) should be considered broken anyway until it is actually tested on a specific platform (and in that case any problems that show up are trivial to fix).

You're right about the macro thing of course.

The typedef-thing is arguable, I would at least try to not let such custom typedefs over basic types leak into the public API of the library where they could collide with typedefs of other libraries (e.g. all public types of a library should have at least a prefix which makes name collisions with other libraries unlikely).

> 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.

There's really no other way for a general allocation function that doesn't know the target type. I would expand the default alignment from 8 to 16 bytes though, because this is what you typically get from malloc on 64-bit targets, and a bigger 'natural alignment' should be extremely rare (maybe needed for some SIMD types, but those are outside the C standard anyway).

> 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.

Unaligned accesses are fast (unless they straddle a cache line or involve SIMD registers) and work perfectly well on current mainstream CPUs (and have been working fine for a long time).

E.g. I'm really not a fan of taking every piece of C code apart because it might not work on an experimental CPU design from the 1960s which the C standard theoretically supports but no current C compiler ;) (exaggerating of course, but there's no way around testing on all expected target compilers and platforms, any target config that's not explicitly tested should be considered unsupported, and that's not even a programming language specific thing).

It's ok as long as the types don't leak into the public API when the code is distributed as a library. But yeah, it looks like a leftover bad habit from pre-C99 times (I suspect the author is on Windows where MSVC was very late to the C99 party), and Microsoft also recommened for a while to build C code via the C++ compiler, which is where the "cast result of malloc" habit might come from.

Typedefing uint32t to u32 etc is extremely common

They wanted shorter aliases for them to make their code clearer, I suppose.

To make them easier to type and more aesthetically pleasing