From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jess Balint Newsgroups: gmane.emacs.bugs Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules Date: Mon, 29 Feb 2016 14:28:14 -0600 Message-ID: References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> <83twkvcg30.fsf@gnu.org> <56D0C9B4.8070105@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e013a084cfb3fb0052cee7ce6 X-Trace: ger.gmane.org 1456777758 23231 80.91.229.3 (29 Feb 2016 20:29:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 29 Feb 2016 20:29:18 +0000 (UTC) Cc: John Wiegley , 22737@debbugs.gnu.org To: Daniel Colascione Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Feb 29 21:29:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aaURK-0004qn-EG for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 21:29:10 +0100 Original-Received: from localhost ([::1]:39018 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaURJ-0006t8-TU for geb-bug-gnu-emacs@m.gmane.org; Mon, 29 Feb 2016 15:29:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56792) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaURF-0006ry-DV for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 15:29:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aaURC-0002rC-4h for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 15:29:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:56981) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aaURC-0002r7-1Y for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 15:29:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aaURB-0005n6-Q5 for bug-gnu-emacs@gnu.org; Mon, 29 Feb 2016 15:29:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jess Balint Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 29 Feb 2016 20:29:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22737-submit@debbugs.gnu.org id=B22737.145677770122212 (code B ref 22737); Mon, 29 Feb 2016 20:29:01 +0000 Original-Received: (at 22737) by debbugs.gnu.org; 29 Feb 2016 20:28:21 +0000 Original-Received: from localhost ([127.0.0.1]:54108 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaUQW-0005mC-UY for submit@debbugs.gnu.org; Mon, 29 Feb 2016 15:28:21 -0500 Original-Received: from mail-ig0-f178.google.com ([209.85.213.178]:36943) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aaUQV-0005m0-P0 for 22737@debbugs.gnu.org; Mon, 29 Feb 2016 15:28:20 -0500 Original-Received: by mail-ig0-f178.google.com with SMTP id z8so3458999ige.0 for <22737@debbugs.gnu.org>; Mon, 29 Feb 2016 12:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fVhOUZJJndtHPsCqrKlfFj2Yqhltkj7NgnUjkk2jt6E=; b=CCvB98Jrpa/QlqRgHNhFCywx/wF69mAhrREiaj0jPrHYykn4vxXqCSgwJ52ZYXrx4F RMBhiMPUX5/ywRpmXjI8p0xhr4hdJ7mJMsmlkYA2C6W86/kTZ6pz4hppSpKmbms7TRBN MDEDfnEJ47nkC8Wj165stKj2p4dEjOLENYraHLrWMr4FvdY5uNyQc4UEE2wO2cyGOXhj LQpeQo2ktj6k7QAMrjQiFtM1sCePA434CUArEbi8eHdkra9WVc3w6vo/ODbcgmx/Os/6 Yb2uLFJ9Owqu0x6Rivk+Q57gCrCBlnIKHGYmQwMbpdvsds5kysNP3u+yxgzwQ8pLhh1/ 7dfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fVhOUZJJndtHPsCqrKlfFj2Yqhltkj7NgnUjkk2jt6E=; b=lCoyD3QbA+U8f8eYJTW0pWCvKut2ttx3enZGHj4aty0ePH96QdWmHhPOHcYhLH90Mk +KtrDTYyhVA6ieQTuv57N73Wj3TbXNLHIFDlauakFcO80d8eGZXPXi/iRAkULEntXfZQ 0J6Whna+L0CVezShCcolOEAgii+b8jx1yGr/Ywv/Gk647P1efzw+Rb/KbGDL22WHsTtq VdbC1jiBtaW0Ghv/cJJRIeeNb12kCES2GKy838PQCB7V7V1wNVrewZ5VzFy0idEMnDHy rSgxv2VxUGa2WWSdZTR2FHp4RBOdJpeN+12RQOXv0cEKAkwYVOW8GJx84k1IHq8JUCFt 3DUg== X-Gm-Message-State: AD7BkJLUi5JFUkp3wYdJK8l1NV+or0FWO61DoyGSZrk+UCyLOTWd8UBn4eQl6WPwVNKGV84MYIQUpc1S0iEdBg== X-Received: by 10.50.117.103 with SMTP id kd7mr2240601igb.57.1456777694230; Mon, 29 Feb 2016 12:28:14 -0800 (PST) Original-Received: by 10.64.223.105 with HTTP; Mon, 29 Feb 2016 12:28:14 -0800 (PST) In-Reply-To: <56D0C9B4.8070105@dancol.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:114164 Archived-At: --089e013a084cfb3fb0052cee7ce6 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 3:55 PM, Daniel Colascione wrote: > On 02/26/2016 01:51 PM, Jess Balint wrote: > > On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii > > wrote: > > > > > Date: Fri, 26 Feb 2016 12:53:20 -0600 > > > From: Jess Balint > > > > Cc: 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 --089e013a084cfb3fb0052cee7ce6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 26, 2016 at 3:55 PM, Daniel Colascione <dancol@dancol.org><= /span> wrote:
On 02/26/2= 016 01:51 PM, Jess Balint wrote:
> On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <eliz@gnu.org
> <mailto:eli= z@gnu.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0> Date: Fri, 26 Feb 2016 12:53:20 -0600
>=C2=A0 =C2=A0 =C2=A0> From: Jess Balint <jbalint@gmail.com <mailto:jbalint@gmail.com>>
>=C2=A0 =C2=A0 =C2=A0> Cc: 2= 2737@debbugs.gnu.org <mailto:22737@debbugs.gnu.org>
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 What will happen if such objects are exp= osed to Lisp, copied or
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 assigned to other Lisp variables, etc.? = Won't this cause all kinds of
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 trouble, like modifying one such object = will magically modify several
>=C2=A0 =C2=A0 =C2=A0>=C2=A0 others, which share its storage?
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This is how C code works. If you return a poin= ter from a function, you may have to free that pointer yourself or
>=C2=A0 =C2=A0 =C2=A0> you may not. You may get the same pointer back= from multiple calls to the same function. If you use the
>=C2=A0 =C2=A0 =C2=A0> pointer after it's been freed, it's yo= ur problem. You need to agree with the owner of the pointer how the
>=C2=A0 =C2=A0 =C2=A0> memory is to be managed. With pointers, modifi= cations to the underlying data are visible by all who have a
>=C2=A0 =C2=A0 =C2=A0> pointer to the data. I wouldn't call this = "magically modifying others".
>
>=C2=A0 =C2=A0 =C2=A0In C, yes.=C2=A0 But we are talking about Lisp obje= cts here.
>
>=C2=A0 =C2=A0 =C2=A0Am I the only one who is uneasy with supporting suc= h Lisp objects?=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0so, I will shut up and install the changes.=C2=A0 D= aniel, John, what's your
>=C2=A0 =C2=A0 =C2=A0opinion on this?
>
>=C2=A0 =C2=A0 =C2=A0Thanks.
>
>
> 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 semanti= c.
> 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<= br> 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.
=C2=A0
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 retur= n nil. Otherwise this will lead to segfaults.

Jess=

--089e013a084cfb3fb0052cee7ce6--