SRFI 199: POSIX errno manipulation Arthur A. Gleckler (26 Jun 2020 02:31 UTC)
Re: SRFI 199: POSIX errno manipulation John Cowan (26 Jun 2020 02:39 UTC)
Re: SRFI 199: POSIX errno manipulation Marc Nieper-Wißkirchen (26 Jun 2020 06:02 UTC)
Re: SRFI 199: POSIX errno manipulation hga@xxxxxx (26 Jun 2020 14:44 UTC)
Re: SRFI 199: POSIX errno manipulation Marc Nieper-Wißkirchen (26 Jun 2020 15:22 UTC)
Re: SRFI 199: POSIX errno manipulation John Cowan (27 Jun 2020 04:03 UTC)
Re: SRFI 199: POSIX errno manipulation Shiro Kawai (27 Jun 2020 09:52 UTC)
Re: SRFI 199: POSIX errno manipulation Shiro Kawai (27 Jun 2020 09:53 UTC)
Re: SRFI 199: POSIX errno manipulation hga@xxxxxx (27 Jun 2020 10:55 UTC)
Re: SRFI 199: POSIX errno manipulation Shiro Kawai (27 Jun 2020 11:12 UTC)
Re: SRFI 199: POSIX errno manipulation Lassi Kortela (27 Jun 2020 11:26 UTC)
Re: SRFI 199: POSIX errno manipulation John Cowan (27 Jun 2020 14:47 UTC)
Re: SRFI 199: POSIX errno manipulation hga@xxxxxx (27 Jun 2020 15:05 UTC)
Re: SRFI 199: POSIX errno manipulation Lassi Kortela (27 Jun 2020 15:12 UTC)
Re: SRFI 199: POSIX errno manipulation hga@xxxxxx (27 Jun 2020 15:40 UTC)
Re: SRFI 199: POSIX errno manipulation Lassi Kortela (27 Jun 2020 15:47 UTC)
Re: SRFI 199: POSIX errno manipulation Shiro Kawai (27 Jun 2020 17:51 UTC)
Re: SRFI 199: POSIX errno manipulation John Cowan (27 Jun 2020 15:49 UTC)

Re: SRFI 199: POSIX errno manipulation Lassi Kortela 27 Jun 2020 11:26 UTC

I agree with Marc and Shiro that there should not be a global procedure
to get the current errno value. The dynamic duo of threads and signals
will be sure to mess this one up -- plus the usual caveats about FFI.

Each Scheme wrapper for a POSIX syscall should return the errno value
after the call as a fixnum (where zero means "no error"). I can't see
any other safe way to do it.