> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Saturday, June 27, 2020 10:12 AM
>
> [...]
>
>> I too am beginning to think that there is no natural client for SRFI
>> 199.  If you want to fake a Posix error, SRFI 198 will allow that, but
>> I think picking up the actual value of errno has to be done (very
>> carefully) in C, where only Posix threads matter.
>
> +1, thanks for listening.
>
>> Doesn't SRFI 198 still need *an* API to get errno from, even if it's not
>> this one?  There's also a general need in POSIX interfacing to set errno
>> before using some system or library calls.  I created SRFI 199 because
>> you don't believe that API should live in SRFI 198.
>
> The Scheme side should get the errno value from the FFI glue procedure
> of each particular syscall. Anything else is error-prone (no pun intended).

In that case, we would drop SRFI 198's errno-error procedure's errno
argument.  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.  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.

> "Set errno to zero before calling a syscall" is an anti-pattern in
> syscall design and there should only be a few syscalls in existence that
> need it.

Indeed, but they do exist, and we must accommodate them.  Shouldn't be
hard as part of a general solution:

> The errno-setting-and-getting should be rolled into the FFI
> glue. IMO, nothing good can come from exposing Unix to Scheme at this
> level of granularity :-) It is "unwarranted chumminess with the
> [operating system]", to steal a phrase from Dennis Ritchie.

I'm open to dropping this from errno-error and modifying my SRFI 170
implementation. We inherited this design from scsh, which is tied to
Scheme 48 and perhaps safely so, without seriously examining it.

- Harold