Then I might have misunderstood you with the issue of propagating errors. In IRQ, as you mentioned, it wouldn't be very practical to blow out the system just because your error propagating mechanism depends on yet another thing that can miserably fail. That's why I thought of tagged pointers, given the sufficiently aligned pointer operation of marking the action as failed cannot be unsuccessful. Nice thing about it is that you also get atomicity basically for free.
> Character/byte pointers often start at unaligned offsets
Yes, but the address of that pointer is still 8 bytes long and idea of using 3 LSB of that address to encode the state is still applicable, isn't it?
> > Character/byte pointers often start at unaligned offsets
> How's that possible? Isn't that an UB?
"Unaligned" was not the best word to use. What I really meant was byte-aligned:
char* s = strdup("Hello world!");
char* p = &s[1];
Here, `p` is byte-aligned and will have a 1 in the least significant position. So a scheme that uses low bits to encode allocation failure would have to work hard to avoid confusing byte-aligned pointers with allocation-failure-signalling pointers.
> Unaligned" was not the best word to use. What I really meant was byte-aligned
Yeah, I figured just few moments after I replied what you actually meant. That's why I edited the post above.
Well, to make it more robust one would have to wrap it in it's own pointer type but I think it's doable. I don't know whether or not it is a wise choice to make it a dependency in the OS though :)
> Character/byte pointers often start at unaligned offsets
Yes, but the address of that pointer is still 8 bytes long and idea of using 3 LSB of that address to encode the state is still applicable, isn't it?