Thanks for your explanation :) One thing I still don't understand though: > This is because `stdint.h` isn't 100% compatible with _every_ platform Linux suppo

Thanks for your explanation :) One thing I still don't understand though: > This is because `stdint.h` isn't 100% compatible with _every_ platform Linux supports. This gets in hair brained definitions of pointers lengths on some obscure platforms. For example SPARC64's `long`, `long long`, `void` , and `uint64_t` aren't all the same size (`long long` is `uint64_t`, while void\ and `long` are `uint32_t`, but in kernel land `voidx` is `uint64_t`). In these cases, you just defined the variably-lengthed types (void* ) using the fixed-length types (uint64_t). This would just demonstrate that the fixed-length types are absolute, and IMO then good candidates to base absolute-sized types on. And yet that's still not good enough? A bit of googling brings up the book Linux Device Drivers 3rd Ed (2005)[1], in which chap11 specifically addresses the topic of types. It argues against the usage of standard C types (int, long, etc) specifically because of their size variability. That's all well and good, but it doesn't make any mention of stdint.h! A hypothesis comes up: maybe stdtint.h is meant to be a user-space header exposed by the system/compiler, and the kernel, having to be entirely bootstrapped, can't even depend on that? So it just redefines the types for itself? With the side-effect of exposing those to userspace at the API? [1] https://lwn.net/Kernel/LDD3/ https://lwn.net/Kernel/LDD3/