In that case, we would drop SRFI 198's errno-error procedure's errno
argument.
errno argument of errno-error is still useful
- If the implementation emulates certain POSIX functionality, it can be used to signal posix error with a selected errno that makes sense.
- If the implementation wraps raw POSIX call, it can propagate the original error.
In the latter case, you can still get the original POSIX errno by wrapping it by guard.
If you don't like the overhead of guard, well, let your implementation expose errno interface; it is not portable anyway.
We do still need to access errno in certain circumstances, like
the infamous PC loser example from Worst is Better, retry in case of
getting a EINTR for certain POSIX calls.
EINTR retry should be handled in the FFI layer, except for selected cases.
Some systems uses signals for inter-thread communication in essential business like GC (e.g. bdw-gc) so EINTR occurs far more likely than usual C programs, and basically you have to wrap almost all posix calls with "if it gets EINTR, restart" loop. It's a lot cleaner to make it handled internally.
If the implementation provides signal handlers in Scheme, the handler should be called before the retly (it is unlikely that you can call Scheme runtime from the real signal handler.) That gives you the opportunity to abort the system call on EINTR. (Signal handler setting is global, so it may also be desirable to customize the behavior per-call basis).
Some other uses of POSIX in
SRFI 170 branch on certain errnos, like terminal?, if the system call
returns ENOTTY we don't consider that an error in a predicate.
Right, it isn't an error. The bottom layer needs to see ENOTTY.
If your implementation implements srfi-170 with bare FFI and internal routines such as (errno), it is totally fine. I just think that's an implementation-specific detail and doesn't need to be exposed. Esp. if the implementation already has the layer that handles these stuff, I see little use of srfi-199.