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

[Luís Oliveira]

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/