[nybble41]

> malloc: Have a big static block of uint8_t and return pointers from it.

According to C99 section 6.5 paragraphs 6-7 that would be undefined behavior. The declared type of the object is uint8_t and you're accessing it through an lvalue expression which is not compatible with uint8_t. (You can access any object through a character-type lvalue, but the reverse is not true.) The malloc() function is required to return memory which is disjoint from any other object—that includes your uint8_t array.

Besides aliasing concerns, your character array may not be properly aligned for whatever type is being stored there and there is no way within the C99 standard to determine the alignment of the array or the required alignment for the stored type.

> exit: longjmp.

That might work, in a single-threaded program, if you longjmp() back to main() and return. There's no telling what might happen if you did that from another thread, of course, but then C99 doesn't really cover threads.

[danmg]

Put the block in a struct and use allignment keywords.

[nybble41]

If you're lucky enough to be using C11 or C18, sure. There are no alignment keywords in C99. However, that still leaves the aliasing issue, and the fact that objects allocated with malloc() are defined not to overlap with any other object.

[danmg]

well you also need another static block for the allocation bitmap or whatever structure you're going to use. How would the pointers that you're generated be aliased if they're unique according to your free map.

[nybble41]

They're aliased with the array that you allocated them from. The compiler is free to assume that elements in an array with a declared type of uint8_t won't be accessed via any other type of lvalue (other than another character type). Doing so is undefined behavior, which means there are no guarantees about how any part of the program behaves before or after such an access. In many cases you can get away with it, of course, but a strictly conforming C program can't rely on that.