Felix Filozov <ffilo...@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
