Not enough type checking on API boundaries

[Luís Oliveira]

James Anderson pointed to some examples of how the CFFI API doesn't perform adequate type checking resulting in cryptic errors coming from CFFI internals: <http://article.gmane.org/gmane.lisp.cffi.devel/2425>

E.g., (foreign-slot-value s 'something-thats-not-a-struct-type 'field) will yield things like:

; caught WARNING:
; Error during compiler-macroexpansion of
; (CFFI::FOREIGN-SLOT-SET #:STORE4 S ...). Use *BREAK-ON-SIGNALS* to
; intercept.
;
; There is no applicable method for the generic function
; #<STANDARD-GENERIC-FUNCTION CFFI::SLOTS (1)>
; when called with arguments
; (#<CFFI::FOREIGN-TYPE SOMETHING-THATS-NOT-A-STRUCT-TYPE>).

We have all the information to properly point out that a struct type was expected but we got something else. We can do it at compile time even.

[james anderson (james-anderson-0)]

given that the reported type of the variable was in all cases a pointer, one would expect all references to succeed.

[Luís Oliveira (luismbo)]

On Thu, Jun 13, 2013 at 2:06 AM, james anderson <email address hidden> wrote:
> given that the reported type of the variable was in all cases a
> pointer, one would expect all references to succeed.

with-foreign-object will always give you a pointer to what has just
been allocated. In some cases your test code is allocating enough
memory to hold a pointer, other times it's allocating enough memory to
hold a struct, but you always get a pointer to that allocated memory.

And since CFFI pointers are untyped, the type you specify when
dereferencing them is crucial.