[cffi-devel] MEM-REF and BARE-STRUCT-TYPE-P issue

[CRLF0710]

2013/1/19 Liam Healy <lnp at healy.washington.dc.us>

> I would prefer to leave the question of aggregate definition to someone
> else, as I am not clear on what constitutes an aggregate.  However, if you
> find code breaking, please post a "before and after" minimal example with
> the previous correct result and the current wrong result.  If you have a
> proposed method to fix the problem, can you add that to your branch and do
> a pull request?
>
Ah, my English is not very good. Actually i meant the code i was writing in
some personal projects are broken and i think it was cffi's bug, sorry.

I can't do a pull request until i knew what is the correct thing to do (and
wrote it down).

Yes, there are several methods to fix it, but that depends on what we think
BARE-STRUCT-TYPE-P should do.

Solution #1
(defmethod bare-struct-type-p ((x foreign-type))
     <return some proper value here>)
Now we provide a default value.

Solution #2
(defmethod bare-struct-type-p ((x foreign-array-type))
     <return some proper value here>)
Add we are asking user to implement bare-struct-type-p for their type
before they can safely call MEM-REF

Solution #3
Modify the MEM-REF code to see if it is a foreign-struct-type or typedef
into a foreign-struct-type first AND call bare-struct-type-p

I'm not sure which is better. Actually i'm not sure what it means to ask a
non-struct type if it is bare(maybe the <proper value> is nil). But i think
solution #1 is the simplest?


> Yes, please.
>
OK. The fix should use BARE-STRUCT-TYPE-P, so after the fix above this will
be fixed in a minute.


-- 
Wir müssen wissen; wir werden wissen!
CrLF.0710
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20130120/7dc8062c/attachment.html>