I am the target audience. I get exactly what he’s going for but found a different gripe.
I really dislike his coding style! It’s written to be “short” in favor of clear. I see what the code does, but not necessarily his intent.
void*page_alloc(unsigned long long bytes) {
void *x;
for(;;) {
x = mmap(0, bytes, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
if(x != MAP_FAILED) return x;
out_of_memory();
}
}
For embedded I stoped using “unsigned long long” in favor of uint64_t. He spends all those extra characters but can’t put a space in the void pointer function definition?
Apologies! I usually typedef long long J;typedef unsigned long long U; and that makes it a bit shorter, but I wanted each example to compile, and not to get bogged down on typedefs.
If you use this kind of typedefs, most people reading your code will kind of hate you... either that or you're targeting the Internationl Obfuscated C Code Contents [1].
My recollection was that size_t and ptrdiff_t were present in c89. size_t was the type yielded by sizeof. This draft appears to corroborate my recollection:
But this is an allocation function, where the amount of data to be allocated is specified in bytes. That must surely use size_t. Imagine the case where 128 bit systems become popular and you want to use this function to allocate 2^70 bytes of memory. Using uint64_t here would be invalid in that case.
If you’re going to allocate like that you could use 8s and get any multiple you like, no?
I’ll give you that there are times for performance you want the native system type. But I would still prefer to use uint32_t and specify this was optimized for a 32bit system.
I really dislike his coding style! It’s written to be “short” in favor of clear. I see what the code does, but not necessarily his intent.
}For embedded I stoped using “unsigned long long” in favor of uint64_t. He spends all those extra characters but can’t put a space in the void pointer function definition?