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

[Jess Balint]

On Fri, Feb 26, 2016 at 3:55 PM, Daniel Colascione <dancol@dancol.org> wrote:

On 02/26/2016 01:51 PM, Jess Balint wrote:
> On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <eliz@gnu.org
> <mailto:eliz@gnu.org>> wrote:
>
>     > Date: Fri, 26 Feb 2016 12:53:20 -0600
>     > From: Jess Balint <jbalint@gmail.com <mailto:jbalint@gmail.com>>
>     > Cc: 22737@debbugs.gnu.org <mailto:22737@debbugs.gnu.org>
>     >
>     >  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.

 

Ok, I can respect that. I don't really agree, but... so be it. If this is the way you want it to work, maybe make_user_ptr() should return nil. Otherwise this will lead to segfaults.

Jess