Returning errno as a second value

[Luís Oliveira]

Felix Filozov <ffilozov at 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