search

ned14 / status-code

Proposed SG14 status_code for the C++ standard
Other
66 stars 13 forks source link

Support non-Windows non-POSIX platforms #18

Closed burnpanck closed 4 years ago

burnpanck commented 4 years ago

I'm trying out Outcome in a forward-looking bare-metal embedded C++ project, and would like to use status_code in anticipation of P0709 Herb Sutter, Zero-overhead deterministic exceptions: Throwing values. Unfortunately, my standard-library (libc++ on newlib) is not quite standard conforming. It is also lacking strerror_r, event though that doesn't seem to be standard C++ either. This in turn prevents <posix_code.hpp> from compiling, which is unconditionally included from <system_code.hpp>. Of course, on bare-metal it's always a bit a luck-shot which standard library features are supported (at least until P0829 Ben Craig, Freestanding proposal), but Outcome seems so fundamental it should definitely be possible to use on bare-metal.

ned14 commented 4 years ago

It is impossible to anticipate in advance all of the possible combinations of C and C++ runtimes which people run. Literally hundreds.

I have accepted pull requests supporting various bare metal systems before, I would have no objection to a PR from you for whatever your specific bare metal system is.

With respect to strerror, the problem is that it is not thread safe. That may not matter to your embedded application, but it's not something one can safely ship as an out of the box default.

burnpanck commented 4 years ago

The fix I used in my application even more simply just doesn't include <posix_code.hpp> at all. It seems to compile fine in the limited use that I have done so far. Is it correct that posix_code is not needed in the standard paper, even though general_code mirrors exactly that? Would a feature-detected conditional inclusion of the header be an acceptable solution? One challenge here obviously is how to reliably detect if the code is to be compiled for a posix system - I have simply tested __linux__ in my use, but something based on __POSIX_VERSION might be closer...

ned14 commented 4 years ago

generic_code maps standardised POSIX codes, but posix_code also maps proprietary POSIX codes. Message strings from the former will be a subset of the possible message strings from the latter. Hence the use of strerror().

ned14 commented 4 years ago

I was thinking about this problem. Right now, the code assumes that if we are not on Windows, then we must be on POSIX.

It seems to me that a solution to your problem would be if status code and Outcome could compile in a non-Windows non-POSIX configuration. That would then also support non-Windows non-POSIX platforms, which seems valuable to me.

What do you think?

burnpanck commented 4 years ago

That would indeed solve my problem. Bare-metal environments simply are not POSIX. For me, the challenge was reliably identifying if a configuration is POSIX. Apparently, every source relying on POSIX behaviour should define __POSIX_VERSION, but I doubt that this is indeed the case.

ned14 commented 4 years ago

Ok, I'll try to get this done in the next few weeks. Thanks for the idea.

ned14 commented 4 years ago

Support added. The WG21 meeting is next week, so adding support to Outcome may take a little longer. Thanks for the suggestion!