Luís Oliveira <luismbo <at> gmail.com> writes: > >>> + (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.
Actually, by throwing in that "format" (which returns nil) you short-circuit the canonicalize recursive call and you no longer get the error because you are no longer calling canonicalize with nil. > >>> &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)). Yeah, that's what I was thinking, too. [snip] Jeez Louise this mailing list management software is annoying! It's complaining about too much quoted text. And top-level posting, FCS. _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
