The Errno Story

[Malcolm Wallace]

Dean Herington <heringto at cs.unc.edu> writes:

> > foreign import ccall_errno "unistd.h chdir" :: Ptr CChar -> IO (CInt,CInt)
> 
> John's first suggested alternative above seems very appealing to me, as it
> seems neatly to fix the fundamental design flaw in `errno`: that determining
> the success/failure of a system call is separated from the call itself.  I'm
> surprised more sentiment in its favor has not shown up.  What are the
> disadvantages of such a solution?

The first and most obvious disadvantage is that the basic FFI currently
has no direct mechanism to return a pair of values.  The idiomatic way to
achieve the same effect is to store the two values in a C structure
and return a pointer to it, unpacking the structure again on the
Haskell side of the interface, and de-allocating the structure
somehow afterwards.

Obviously this is a tedious and mechanical job to go through, but this
is exactly the province of tool support, rather than the basic FFI.
There are already tools that support this idiom (e.g. GreenCard),
and you can already write your errno bindings this way if you want to.
For instance:

  %#include <errno.h>
  %fun chdir :: Ptr CChar -> IO (CInt,CInt)
  %call   (ptr cd)
  %code   res=chdir(cd);
  %result (cint res, cint errno)

Regards,
    Malcolm