[cffi-devel] Re: CFFI::CANONICALIZE with arguments (NIL)

[Lou Vanek]

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.