Table of Contents
Errors
Every error cl-ffi signals is an ffi-error, and each says what was wrong
and what to write instead.
| Condition | Signalled when | Readers |
|---|---|---|
load-foreign-library-error |
no file of a library's definition or spec could be loaded, or no clause fits the platform | load-foreign-library-error-library, the name or spec; load-foreign-library-error-attempts, a list of (file reason) |
encoding-error |
a string holds a character its encoding cannot represent | encoding-error-encoding, encoding-error-character |
decoding-error |
foreign bytes are no valid string in the encoding asked for | decoding-error-encoding, decoding-error-position, the byte where it goes wrong |
ffi-error |
anything else: an unknown type, struct slot, enum keyword, callback or library; a struct read as a scalar; memory malloc cannot give |
Misuse that the types say at compile time is refused there: mem-ref of a
struct type, foreign-slot-value of an array slot, a struct passed by
value. SBCL warns when it compiles such code, and signals the error when
it runs.
An argument of the wrong kind is a type-error, not an ffi-error.
cl-ffi's own functions declaim the full domain of their arguments: the
encodings for :encoding, the shape of a type specifier, of a struct or
union specifier and of a library's spec, the name of a defined type for
the enum and bitfield functions. SBCL checks them when the function is
called, before cl-ffi looks at the argument, and warns of a constant one
when it compiles the call. A malformed type specifier, such as
(:string :size 4), or a spec within (:or ...) is still an ffi-error,
from cl-ffi as it reads it.
A defcfun function's arguments are checked the same way against the
ftype it declaims, which signals a type-error for a value of the wrong
type before cl-ffi's own conversion would.