[Cffi-devel] Fw: Fw: Fw: Help perfecting my GC finalizer/constructor

[Joeish W]

I just understood what you meant by this:

(defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat))
    (values  (c-pointer lisp-value) lisp-value)


Ok, so great!...I can now mem-aref without adding the c-pointer..so thank you very much for that, but is there a way I can do the same type of thing to let me foreign-alloc it without adding c-pointer.


On Wednesday, April 30, 2014 9:15 AM, Martin Simmons <martin at lispworks.com> wrote:
 
>>>>> On Tue, 29 Apr 2014 07:20:08 +0200, Willem Rein Oudshoorn said:
>> Cancel-Lock: sha1:p0/p2S+buMdADzjMLfHl6LN5m6k=
>> 
>> Martin Simmons <martin at lispworks.com> writes:
>> 
>> >>>>>> On Mon, 28 Apr 2014 07:26:07 +0200, Willem Rein Oudshoorn said:
>> >> Cancel-Lock: sha1:zqpk08tO/PaCrz3PLTlI+ocAF9E=
>> >> 
>> >> Joeish W <joeish80829 at yahoo.com> writes:
>> >> 
>> >> > How do I work with the metaobjects(is that what they are called)
>> >> > output by the code you gave me...If you can show me how to mem-aref
>> >> > one I would really appreciate it
>> >> 
>> >> Sorry for the short answer, but at the moment I am extremely busy.
>> >> If you followed the example
>> >> 
>> >>  (mem-aref (c-pointer YOUR-POINT) ...)
>> >> 
>> >> should work.
>> >
>> > It might be interesting (or scary depending on your point of view) to consider
>> > what happens if the variable YOUR-POINT is the last reference to the CLOS
>> > object here...the finalizer might free the foreign object before mem-aref is
>> > entered if the compiler no longer keeps a pointer to the variable.
>> >
>> No this is not safe.  In general you should never do 
>> `(c-pointer ...)` outside the low level parts of the bindings, and use
>> it very carefully.
>> 
>> Personally I would try to never use the `c-pointer` method outside
>> the `translate-to-foreign` code.   And I naively expected that this
>> would be safe.   But as you point out:
>> 
>> > Or more specifically, can this ever be safe?
>> >
>> > (mem-aref (c-pointer (point0)) ...)
>> 
>> This is never safe.
>> 
>> I think the easiest fix is to change the 
>> 
>>   (defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat))
>>     (c-pointer lisp-value))
>> 
>> code to  [UNTESTED CODE]:
>> 
>> 
>>   (defmethod translate-to-foreign ((lisp-value cv-matrix) (c-type cv-mat))
>>     (values  (c-pointer lisp-value) lisp-value)
>> 
>> 
>> This should keep the lisp-value around until we are done using the
>> `(c-pointer ...)` value.   Provided of course you are not mucking around
>> with the `c-pointer` method yourself.
>> 
>> 
>> In general, I would advocate to hide all the nasty c-pointer business in
>> the translate methods and never deal with it outside that limited scope.
>> 
>> 
>> Thank you for bringing this to my attention.  I do think we need a paper
>> or section in the manual on how to deal with combing GC in Lisp and
>> manual memory management on the C side.  
>> 
>> When my time frees up (hopefully in a month or two)  I might take a stab 
>> at a first draft.
>
>IMHO, it needs to come with a huge security warning, otherwise there will be
>endless use-after-free bugs when users lose the wrapper object after storing
>the pointer somewhere.
>
>
>__Martin
>
>_______________________________________________
>Cffi-devel mailing list
>Cffi-devel at common-lisp.net
>http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20140430/9c8f6897/attachment.html>