headers
Stelian Ionescu | 30 Apr 2012 20:30
Gravatar

*parse-bare-structs-as-pointers*

Dow we really need *parse-bare-structs-as-pointers* ? It's only used in
one place(parse-deprecated-struct-type) and IMO it's useless: we should
parse bare structs as pointers unconditionally and issue a warning that
it's deprecated and will be removed on 2013-05-01

--

-- 
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
http://common-lisp.net/project/iolib


_______________________________________________
cffi-devel mailing list
cffi-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
Permalink | Reply |
headers
Luís Oliveira | 1 May 2012 02:14
Picon
Gravatar

Re: *parse-bare-structs-as-pointers*

On Mon, Apr 30, 2012 at 7:30 PM, Stelian Ionescu <sionescu <at> cddr.org> wrote:
> Dow we really need *parse-bare-structs-as-pointers* ? It's only used in
> one place(parse-deprecated-struct-type) and IMO it's useless: we should
> parse bare structs as pointers unconditionally and issue a warning that
> it's deprecated and will be removed on 2013-05-01

This is a good question. I was wondering about this myself, since I
couldn't quite remember why I had introduced it. Turns out it is
necessary. The problem is that struct types used to behave as pointers
in some situations and as aggregate types in others. Blindly
converting every RANDOM-STRUCT-TYPE to (:POINTER (:STRUCT
RANDOM-STRUCT-TYPE)) would lead to incorrect results in various
places: FOREIGN-TYPE-SIZE, FOREIGN-SLOT-VALUE, DEFCSTRUCT, etc.

We might be able to simplify the code a little bit if we flipped its
default value to be true, though.

In any case, we already issue a deprecation warning, and we should
definitely remove this backwards compatibility mess at some point. Not
sure about the time frame, though. After the next CFFI release, we'll
wait and see how fast CFFI-using libraries adapt.

--

-- 
Luís Oliveira
http://r42.eu/~luis/
Permalink | Reply |

Gmane