[plt-scheme] FFI + errno

From: Thomas Chust (chust at web.de)
Date: Mon Dec 21 09:29:26 EST 2009

Eli Barzilay schrieb:
> On Dec 21, Thomas Chust wrote:
>> with something like
>>    (_fun _bytes
>>          -> (res : _int) (errno : (_errno 'posix))
>>          -> (if (equal? res -1)
>>                 (error 'errno "~a" errno)
>>                 res))
>> where _errno would be a special output type expression.
>> Of course it would be functionally equivalent, but I think this
>> variant looks cleaner and is more in the Scheme spirit since it
>> treats the additional error code output of the function as an output
>> instead of replicating the strange behaviour of C by storing a
>> function output in a thread local parameter for no added value.
> I'm not sure what exactly bothers you: the fact that this is
> implemented with a thread cell (which you don't really have to see)
> and you prefer to avoid the global, or the fact that getting the value
> is not too schemely.
> [...]


both of these points bother me: The thread cell because I think it may
become a performance problem and the interface because I don't consider
it very elegant.

However I don't feel strongly about these things. If it is technically
much more difficult to pass errno around in some other way, I don't
think it's really worth the effort. Any good FFI interface for a library
will try to hide the error handling via return codes and errno from the
Scheme side anyway and how the FFI code looks internally is a minor
stylistic issue in my eyes.

> [...]
> If it's the former, then fixing it would involve changing C code to
> accept some way to store the errno (eg, passing in a box, or a setter
> function), and then changing the `_fun' interface to communicate such
> a receiver.
> [...]

Hmm, I know too little about the internal workings of foreign function
call stub generation in PLT to comment on this, but I think its a good
opportunity to have a look at the source code and see whether I can come
up with some clever way to implement my proposal :-)


When C++ is your hammer, every problem looks like your thumb.

Posted on the users mailing list.