3 ms·

We don't use C++ exceptions anywhere in SerenityOS. Instead we use an ErrorOr<T>[1] return type for functions that may fail. These are then automatically propag

by akling 5y ago

We don't use C++ exceptions anywhere in SerenityOS. Instead we use an ErrorOr<T>[1] return type for functions that may fail. These are then automatically propagated by use of a TRY() macro[2]. I haven't thought about encoding allocation failure as a low pointer value. I suppose you could, but it'd only work for pointers with sufficient alignment. Character/byte pointers often start at unaligned offsets when not coming directly from an allocator. Either way, I'm not sure compressing this information would solve any real problem we're having. [1] https://github.com/SerenityOS/serenity/blob/master/AK/Error.h https://github.com/SerenityOS/serenity/blob/master/AK/Error.... [2] https://github.com/SerenityOS/serenity/blob/master/AK/Try.h https://github.com/SerenityOS/serenity/blob/master/AK/Try.h

menaerus 5y ago
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?
- akling 5y ago
  > > 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.
  - menaerus 5y ago
    > 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 :)

by akling 5y ago

menaerus 5y ago

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?

akling 5y ago
> > 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.
- menaerus 5y ago
  > 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 :)