On 2006-maj-20, at 17:01, Lou Vanek wrote:
+++ cffi/src/early-types.lisp 2006-05-20 08:47:59.708847000 -0400
@@ -266,7 +266,10 @@
(defmethod canonicalize ((type foreign-type-alias))
"Return the built-in type keyword for TYPE."
- (canonicalize (actual-type type)))
+ (let ((atype (actual-type type)))
+ (if (null atype)
+ (format *standard-error* "WARNING! null base-type.")
+ (canonicalize atype))))
I'll probably put an (assert (not (null (actual-type type))))
there instead.
I don't think you want an assert here.
I think I do, because (canonicalize nil) will signal an error anyway
as mentioned in the subject.
-(cffi::define-type-spec-parser uffi-array (element-type count)
+(cffi::define-type-spec-parser uffi-array (element-type
&optional count)
[...]
What's the rationale behind this change? I'm guessing it has
something to do with def-array-pointer, but I think there's more
to it.
This change was necessary for those times when you don't know how
large
the array is going to be. Specifically, for this line in mysql-
api.lisp:
(uffi:def-array-pointer mysql-row (* :unsigned-char))
Right. Looking at some code, it seems that UFFI's undocumented array
type is in fact meant to work as (:array element-type &optional
(count 1)).
I like the idea of putting in in uffi-compat since I would notice
it there because that's one of the first places I would look for it.
But I would mention this in the README, as well.
uffi-compat should have its own chapter in the manual, definitely.
That's in the TODO list.
--
Luís Oliveira
http://student.dei.uc.pt/~lmoliv/
_______________________________________________
cffi-devel mailing list
cffi-devel@common-lisp.net
http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
