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.