[cffi-devel] Semantics of defctype*
![](https://secure.gravatar.com/avatar/cdf852bf7c33a9a52527725cf1424286.jpg?s=120&d=mm&r=g)
Hi. I was trying to get Verrazano up and running on my machine, and I noticed that generated bindings would not happily C-c C-k for me in Emacs. I reduced it to the following test case: --- some-file.lisp --- (in-package :cl-user) (defpackage :test-package (:use :cffi :common-lisp)) (in-package :test-package) (cffi::defctype sqlite-int64 :long-long) (cffi::defctype* sqlite-int99 :long-long) (cffi:defcfun ("foo" foo) :int (arg1 sqlite-int64)) (cffi:defcfun ("bar" bar) :int (arg1 sqlite-int99)) --- end some-file.lisp --- If you're in a SLIME session with CFFI already loaded, compiling this file once will result in an error. Compiling it again will make it work. If you compile just the cffi:defctype* declaration with C-c C-c, then try compiling the file, it works. Presumably, defcfun wants the types in its arg lists to be available at compile time, and defctype* doesn't make them available? That said, we shouldn't really be using defctype* at all, right? Slightly more clever processing of definitions should obviate any need for it. Sincerely, Rayiner Hashem
![](https://secure.gravatar.com/avatar/326b108ffcc42f27628703b0c11ed239.jpg?s=120&d=mm&r=g)
On 01/09/07, Rayiner Hashem <rayiner@gmail.com> wrote:
If you compile just the cffi:defctype* declaration with C-c C-c, then try compiling the file, it works.
That version of DEFCTYPE* is missing an EVAL-WHEN. This was fixed by Tomi Borbely a few weeks ago but I forgot to push it to the main tree. Should be fixed now, thanks. -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
![](https://secure.gravatar.com/avatar/326b108ffcc42f27628703b0c11ed239.jpg?s=120&d=mm&r=g)
On 01/09/07, Rayiner Hashem <rayiner@gmail.com> wrote:
That said, we shouldn't really be using defctype* at all, right? Slightly more clever processing of definitions should obviate any need for it.
Forgot to reply to this bit. So, we could make DEFCTYPE behave like DEFCTYPE*, i.e. defer the type instantiation until parse-time. IIRC, the only disadvantage is that you don't get an immediate error on (defctype foo some-typo-here). -- Luís Oliveira http://student.dei.uc.pt/~lmoliv/
![](https://secure.gravatar.com/avatar/cdf852bf7c33a9a52527725cf1424286.jpg?s=120&d=mm&r=g)
Forgot to reply to this bit. So, we could make DEFCTYPE behave like DEFCTYPE*, i.e. defer the type instantiation until parse-time. IIRC, the only disadvantage is that you don't get an immediate error on (defctype foo some-typo-here).
I think defctype's semantics are reasonable as-is. However, in retrospect, I also think it's handy to have something out of box (like defctype*) that more closely mimics the semantics of C's typedef. So the status quo seems fine to me :) Sincerely, Rayiner Hashem
participants (2)
-
Luís Oliveira
-
Rayiner Hashem