"Luís Oliveira" luismbo@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.