[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22737: 25.1; Finalizer should be optional in dynamic modules

From: Daniel Colascione
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Date: Fri, 26 Feb 2016 13:55:00 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

On 02/26/2016 01:51 PM, Jess Balint wrote:
> On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <address@hidden
> <mailto:address@hidden>> wrote:
>     > Date: Fri, 26 Feb 2016 12:53:20 -0600
>     > From: Jess Balint <address@hidden <mailto:address@hidden>>
>     > Cc: address@hidden <mailto:address@hidden>
>     >
>     >  What will happen if such objects are exposed to Lisp, copied or
>     >  assigned to other Lisp variables, etc.? Won't this cause all kinds of
>     >  trouble, like modifying one such object will magically modify several
>     >  others, which share its storage?
>     >
>     > This is how C code works. If you return a pointer from a function, you 
> may have to free that pointer yourself or
>     > you may not. You may get the same pointer back from multiple calls to 
> the same function. If you use the
>     > pointer after it's been freed, it's your problem. You need to agree 
> with the owner of the pointer how the
>     > memory is to be managed. With pointers, modifications to the underlying 
> data are visible by all who have a
>     > pointer to the data. I wouldn't call this "magically modifying others".
>     In C, yes.  But we are talking about Lisp objects here.
>     Am I the only one who is uneasy with supporting such Lisp objects?  If
>     so, I will shut up and install the changes.  Daniel, John, what's your
>     opinion on this?
>     Thanks.
> All I'm asking for is to allow the code to accept a NULL finalizer. This
> means no finalizer will be called. It's a clear and simple semantic.
> Upside is that I (and others who do not want Emacs to free their
> pointers) will not have to create a no-op function unnecessarily to
> supply a finalizer to Emacs.

A no-op function is trivial though; creating it forces you to think
about whether you actually need to free the resulting memory. I think
it's more important to discourage memory leaks and simplify the
semantics of the finalizer parameter than to make this rare (I think)
use case slightly easier for module implementors.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]