[cffi-devel] Safe errno collection

[John Fremlin]

"Luís Oliveira" <luismbo at gmail.com> writes:
[...]
> I'm just trying to follow the usual CFFI philosophy: figure out the
> minimal CFFI-SYS operations required and implement the rest in the
> CFFI package. So far that'd be something like: GET-ERRNO, SET-ERRNO
> and WITHOUT-WHATEVER in CFFI-SYS, and an ERRNO symbol macro in CFFI
> (optional) and something along the lines of Osicat's ERRNO-WRAPPER.

I don't know that there is any need to do set-errno?

In terms of the philosophy, the Linux kernel syscalls actually do not
know about errno. If they return a number between -1 and -4096 or so
then it is treated as an errno and libc will set the special errno
variable. So if we could call the syscalls more directly we would avoid
this problem on Linux. (I think on FreeBSD it might be different.)

> I wonder if you can find out what hoops Allegro has to jump through to
> ensure errno is right?

I can pester Duane about it again and see if we get a definite answer
about the GC stuff.

>> The idea that GC must not modify errno must be false on at
>> least a few implementations ;-)
>
> Sounds like we could test that in the test suite.

It is hard to get a definitive answer but a good approximation can be
tried for.

>> We should not pretend that it is possible to get errno at an arbitrary
>> point after a foreign function call.
>
> Yeah, but I still haven't fully understood the exact failure cases.
> Also, it sounds like this sort of thing would be problematic for all
> sorts of stateful C APIs.

The problem with errno is that it is modified by many function calls
that are necessarily used by the Lisp environment (e.g. IO, memory maps,
etc.). 

Most C APIs will not have this problem because the Lisp environment does
not use them.