>> 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.

The current definition of `errno-error` is:

(errno-error errno procedure-name syscall-name obj ...)

"Constructs a syscall error object s. The message field of s should
incorporate procedure-name (a symbol, the name of the Scheme procedure
that called errno-error), syscall-name (a symbol, the name of the system
call that failed), and an error message string associated with errno [...]"

All of that looks entirely reasonable to me.

However, the same FFI glue that returns the syscall-name to Scheme,
should return the errno value (a fixnum where zero means "no error") as
well.

> 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.

PC losering should also be dealt with in the FFI glue. Or is there a
case where a system call should not be retried on EINTR?

> 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.

That's fair enough, but should also be dealt with on the C side.

>> "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 problem is that the general solution would be an abstraction that
fundamentally decouples the errno-setting syscalls from the
errno-getting Scheme procedures. People will then expect the
errno-getters to work naturally, which is hard for the Scheme
implementation to guarantee in the presence of threads, signals and FFI.

>> 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.

I have seriously examined enough Unix/C code to err on the side of a
little paranoia and obstinate simplicity :) 0.02