<br><br><div class="gmail_quote">On Thu, Apr 19, 2012 at 9:50 AM, Stelian Ionescu <span dir="ltr"><<a href="mailto:sionescu@cddr.org">sionescu@cddr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">On Thu, 2012-04-19 at 14:37 +0100, Luís Oliveira wrote:<br>
> On Thu, Apr 19, 2012 at 11:34 AM, Stelian Ionescu <<a href="mailto:sionescu@cddr.org">sionescu@cddr.org</a>> wrote:<br>
> > IMO the change to mem-aref is bad and will break a lot of code. Until<br>
> > now the contract of mem-aref was that it received a pointer to an array<br>
> > of the referenced type and returned a pointer offset into the array.<br>
> > The fact that it now returns a list is a gratuitous change, with no<br>
> > utility. If we actually want these semantics(not sure about it), it<br>
> > should be mem-aptr to implement them<br>
><br>
> If it's not too difficult, can you extract a self-contained test case<br>
> that has been broken?<br>
<br>
</div>(defcstruct timespec (sec :int64) (usec :int64))<br>
<br>
(with-foreign-object (p '(:struct timespec) 2)<br>
  (mem-aref p '(:struct timespec) 1))<br>
<br>
In order not to break existing code, I think that mem-aref should<br>
continue to return a pointer in this case instead of a plist. That would<br>
allow cffi-using code to work as it is and not have to be rewritten(an<br>
example that was brought to my attention is<br>
<a href="https://gitorious.org/commonqt/commonqt/blobs/master/info.lisp#line312" target="_blank">https://gitorious.org/commonqt/commonqt/blobs/master/info.lisp#line312</a>).<br>
<br>
Since both functionalities will continue to be present in CFFI, it's<br>
better not to force users to review their code to decide, for each use<br>
of mem-aref, whether it needs to be converted to mem-aptr or not.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Stelian Ionescu a.k.a. fe[nl]ix<br>
Quidquid latine dictum sit, altum videtur.<br>
<a href="http://common-lisp.net/project/iolib" target="_blank">http://common-lisp.net/project/iolib</a><br>
<br>
</div></div></blockquote></div><br><div>As Luis pointed out, no code should be broken because '(:struct foo) wasn't used before.  The example you point to has a symbol representing the type '|struct MethodMap| which I guess is being interpreted as if it were'(:struct MethodMap).  I'm not sure, but that's the only way I can see this not being interpreted as a bare structure.  If it were interpreted as a bare structure, everything should work as before.</div>

<div><br></div><div>Liam</div>