Felix Filozov ffilozov@gmail.com writes:
In Allegro CL, the only safe way to get errno after a foreign function call is to configure the foreign function definition to return it as a second value.
Why does that happen. Is it because interrupt handlers may call functions that overwrite errno?
CFFI doesn't deal with errno. There has been some previous discussion (http://lists.common-lisp.net/pipermail/cffi-devel/2009-January/003017. html) to return errno safely, but doesn't seem like it went anywhere.
Re-reading that was useful. Thanks for the pointer.
To sum that discussion up: it'd nice to have cffi-sys:get-errno plus a cffi-sys:without-3rd-party-messing-of-errno so we can implement errno handling in the portable side of CFFI.
Do you think that cffi-sys:without-3rd-party-messing-of-errno macro is feasible? If not, we'll have to place the abstraction at the %FOREIGN-FUNCALL level as you suggest.
So any library that tries to get errno is potentially broken in Allegro CL. I'm seeing this in practice with lisp-zmq, for example.
Out of curiosity, what's messing with errno in your case?
I'd like to introduce a new option to defcfun and foreign-funcall called :errno.
It would look like this: (foreign-funcall ("strlen" :errno t) :string "foo" :int), or (defcfun (strlen "strlen" :errno t) :int (s :string)).
Calling (strlen) would return two values, the return value of the foreign call, and errno.
In some Lisps, the only way to get errno is to make an additional foreign call. Then perhaps that call could be made by CFFI and returns as the second value.
That makes sense. Except for the second value bit because CFFI types can yield more than one value. Alternatives that pop up:
1. Return it as the first value. (Probably requires some multiple-value-list mangling which might not be acceptable performance-wise?)
2. Have the foreign function accept an extra errno argument that takes some structure than can be modified with the errno value.
Not quite happy with either. Any other ideas?
Since CFFI delegates the handling of errno to the implementation, perhaps we could preserve the status quo and not get bugged down in grandiose plans of portability.
CFFI /is/ a grandiose excursion into portability. :-)
Luís