GNU logs - #22737, boring messages


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 18 Feb 2016 21:58:02 +0000
Resent-Message-ID: <handler.22737.B.145583263725336 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: 22737 <at> debbugs.gnu.org
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.145583263725336
          (code B ref -1); Thu, 18 Feb 2016 21:58:02 +0000
Received: (at submit) by debbugs.gnu.org; 18 Feb 2016 21:57:17 +0000
Received: from localhost ([127.0.0.1]:33293 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aWWZZ-0006aZ-Dw
	for submit <at> debbugs.gnu.org; Thu, 18 Feb 2016 16:57:17 -0500
Received: from eggs.gnu.org ([208.118.235.92]:56261)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTX-0006R6-DN
 for submit <at> debbugs.gnu.org; Thu, 18 Feb 2016 16:51:03 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTR-0005yv-C8
 for submit <at> debbugs.gnu.org; Thu, 18 Feb 2016 16:50:58 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM,
 UNPARSEABLE_RELAY autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:55582)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTR-0005ym-96
 for submit <at> debbugs.gnu.org; Thu, 18 Feb 2016 16:50:57 -0500
Received: from eggs.gnu.org ([2001:4830:134:3::10]:47230)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTQ-0005tn-CS
 for bug-gnu-emacs@HIDDEN; Thu, 18 Feb 2016 16:50:57 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTL-0005to-CL
 for bug-gnu-emacs@HIDDEN; Thu, 18 Feb 2016 16:50:56 -0500
Received: from userp1040.oracle.com ([156.151.31.81]:43556)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <jbalint@HIDDEN>) id 1aWWTL-0005te-4i
 for bug-gnu-emacs@HIDDEN; Thu, 18 Feb 2016 16:50:51 -0500
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234])
 by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id
 u1ILonnR005919
 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK)
 for <bug-gnu-emacs@HIDDEN>; Thu, 18 Feb 2016 21:50:50 GMT
Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72])
 by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u1ILomh8003950
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL)
 for <bug-gnu-emacs@HIDDEN>; Thu, 18 Feb 2016 21:50:49 GMT
Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16])
 by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u1ILomv4002880
 for <bug-gnu-emacs@HIDDEN>; Thu, 18 Feb 2016 21:50:48 GMT
Received: from rukh (/10.154.117.160) by default (Oracle Beehive Gateway v4.0)
 with ESMTP ; Thu, 18 Feb 2016 13:50:48 -0800
From: Jess Balint <jbalint@HIDDEN>
User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1
 (x86_64-unknown-linux-gnu)
Date: Thu, 18 Feb 2016 15:52:55 -0600
Message-ID: <87a8mxsn2g.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Mailman-Approved-At: Thu, 18 Feb 2016 16:57:16 -0500
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)


Dynamic modules are really cool so far, but I think finalizers should
not be mandatory for user pointers (alloc.c):

#ifdef HAVE_MODULES
	      else if (mblk->markers[i].m.u_any.type == Lisp_Misc_User_Ptr)
		{
		  struct Lisp_User_Ptr *uptr = &mblk->markers[i].m.u_user_ptr;
		  uptr->finalizer (uptr->p); <----- should NULL-check first
		}
#endif

c.f. https://github.com/emacs-mirror/emacs/blob/master/src/alloc.c#L6893

Thanks!

Jess




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Jess Balint <jbalint@HIDDEN>
Subject: bug#22737: Acknowledgement (25.1; Finalizer should be optional in
 dynamic modules)
Message-ID: <handler.22737.B.145583263725336.ack <at> debbugs.gnu.org>
References: <87a8mxsn2g.fsf@HIDDEN>
X-Gnu-PR-Message: ack 22737
X-Gnu-PR-Package: emacs
Reply-To: 22737 <at> debbugs.gnu.org
Date: Thu, 18 Feb 2016 21:58:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 22737 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
22737: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D22737
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 19 Feb 2016 09:35:02 +0000
Resent-Message-ID: <handler.22737.B22737.14558744504755 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jess Balint <jbalint@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.14558744504755
          (code B ref 22737); Fri, 19 Feb 2016 09:35:02 +0000
Received: (at 22737) by debbugs.gnu.org; 19 Feb 2016 09:34:10 +0000
Received: from localhost ([127.0.0.1]:33500 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aWhRy-0001Ed-I2
	for submit <at> debbugs.gnu.org; Fri, 19 Feb 2016 04:34:10 -0500
Received: from eggs.gnu.org ([208.118.235.92]:32966)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <eliz@HIDDEN>) id 1aWhRw-0001EP-Rq
 for 22737 <at> debbugs.gnu.org; Fri, 19 Feb 2016 04:34:09 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1aWhRo-00009U-IH
 for 22737 <at> debbugs.gnu.org; Fri, 19 Feb 2016 04:34:03 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42961)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1aWhRo-00009M-FM; Fri, 19 Feb 2016 04:34:00 -0500
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2868
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1aWhRn-0000Rv-LD; Fri, 19 Feb 2016 04:34:00 -0500
Date: Fri, 19 Feb 2016 11:33:55 +0200
Message-Id: <83lh6hrqm4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <87a8mxsn2g.fsf@HIDDEN> (message from Jess Balint on Thu, 18
 Feb 2016 15:52:55 -0600)
References: <87a8mxsn2g.fsf@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> From: Jess Balint <jbalint@HIDDEN>
> Date: Thu, 18 Feb 2016 15:52:55 -0600
> 
> Dynamic modules are really cool so far, but I think finalizers should
> not be mandatory for user pointers (alloc.c):
> 
> #ifdef HAVE_MODULES
> 	      else if (mblk->markers[i].m.u_any.type == Lisp_Misc_User_Ptr)
> 		{
> 		  struct Lisp_User_Ptr *uptr = &mblk->markers[i].m.u_user_ptr;
> 		  uptr->finalizer (uptr->p); <----- should NULL-check first
> 		}
> #endif
> 
> c.f. https://github.com/emacs-mirror/emacs/blob/master/src/alloc.c#L6893

Can you tell more about the use case where you needed this change?  A
user-pointer holds a pointer to some unspecified data, and that data
needs to be free'd when the user-pointer object is GC'ed; failure to
do so will cause memory leaks.  When is the above incorrect, or gets
in your way?

Thanks.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 23 Feb 2016 22:48:01 +0000
Resent-Message-ID: <handler.22737.B22737.145626764016534 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145626764016534
          (code B ref 22737); Tue, 23 Feb 2016 22:48:01 +0000
Received: (at 22737) by debbugs.gnu.org; 23 Feb 2016 22:47:20 +0000
Received: from localhost ([127.0.0.1]:41754 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aYLjk-0004Ic-3T
	for submit <at> debbugs.gnu.org; Tue, 23 Feb 2016 17:47:20 -0500
Received: from mail-io0-f174.google.com ([209.85.223.174]:36039)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aYLjh-0004IO-Tp
 for 22737 <at> debbugs.gnu.org; Tue, 23 Feb 2016 17:47:18 -0500
Received: by mail-io0-f174.google.com with SMTP id l127so5766811iof.3
 for <22737 <at> debbugs.gnu.org>; Tue, 23 Feb 2016 14:47:17 -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:content-type;
 bh=D2o9Im5OiCGGlm498cTQYd5ZH7itTh4HI5XkwHO4Fi4=;
 b=JsD/65IJsjzgcMhFQo6Q5IbsDgutZZ+KAAgWSqekoJIUD+k4e0zLmOBGoiUymZysxi
 ARmUQo2i1RUUMkNv26ZXU0ruqyxwBqw3RIFNFcuQiiTlpAQhrsChN8FSBm5jiB6lZSsN
 7C0/JY7pdzTcrL/rgwaE07Lbgxurz/FLoPgV7wV058sUDBTsxi2Z3+jK3rJfxtKNL3rZ
 2lCvbMY5Fnm34V2e+gs6c4J7oTrIXnsS0ne53+YiIDcOltkLAtvqZFKwCOHx7ty7cFRP
 Q22nB3aUO0OspQGe2EVu/68miPRPwvIh3VdHRGFoGuYDw8CfUnWqYJhWPChQLa3VKJNq
 8Kcw==
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:content-type;
 bh=D2o9Im5OiCGGlm498cTQYd5ZH7itTh4HI5XkwHO4Fi4=;
 b=Rm7aRDfYUBIt9ulaQy1yBTzGXnTeZ1xBL2qSVKxJkEWIl9fWUdjBbL4lBEdSbbEGUa
 ePMoj527Z4zdWsv/0O9H3LLtJqtxZt13QipAewGAn+zY2DAD9qFFXHOOkyh4G9yynm7y
 5ru9vScobYubv2jttXPJ14LCrzXDapA1lV8Q2uxk36xeJ44FQ9/BfD+lxNXF2kviNAax
 B/Q0gpvnYJIRNGjpdTXtnryq9zDGQhztrslm9v2nhJWtxGZIZdP1qW9KdmNnHeRkrMhZ
 e9SNJp2hQdIDY4B9Aq51+dru6UvBw56hhhJisK4An33o/ilC2hSkNeQn2vAhPQ4l+3rx
 deQA==
X-Gm-Message-State: AG10YOTXWN4t7t+yG47hhteBY5zB7vmvwnrzVirVsqjfI4pbj6PnZ547vkfvnUl6uCFKkEdmbikrvw3Bs1ruig==
MIME-Version: 1.0
X-Received: by 10.107.63.2 with SMTP id m2mr41415541ioa.7.1456267632320; Tue,
 23 Feb 2016 14:47:12 -0800 (PST)
Received: by 10.64.223.105 with HTTP; Tue, 23 Feb 2016 14:47:12 -0800 (PST)
In-Reply-To: <83lh6hrqm4.fsf@HIDDEN>
References: <87a8mxsn2g.fsf@HIDDEN>
	<83lh6hrqm4.fsf@HIDDEN>
Date: Tue, 23 Feb 2016 16:47:12 -0600
Message-ID: <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
From: Jess Balint <jbalint@HIDDEN>
Content-Type: multipart/alternative; boundary=94eb2c06b69cec431c052c77ba3e
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--94eb2c06b69cec431c052c77ba3e
Content-Type: text/plain; charset=UTF-8

If the data is unspecified it doesn't *necessarily* need to be freed. If I
return a pointer to some global data then I need to create a no-op
finalizer just to please this GC code. In some cases I will be managing
memory a bit more manually and don't care to have Emacs doing anything for
me.

Thx.

Jess

On Fri, Feb 19, 2016 at 3:33 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Jess Balint <jbalint@HIDDEN>
> > Date: Thu, 18 Feb 2016 15:52:55 -0600
> >
> > Dynamic modules are really cool so far, but I think finalizers should
> > not be mandatory for user pointers (alloc.c):
> >
> > #ifdef HAVE_MODULES
> >             else if (mblk->markers[i].m.u_any.type == Lisp_Misc_User_Ptr)
> >               {
> >                 struct Lisp_User_Ptr *uptr =
> &mblk->markers[i].m.u_user_ptr;
> >                 uptr->finalizer (uptr->p); <----- should NULL-check first
> >               }
> > #endif
> >
> > c.f. https://github.com/emacs-mirror/emacs/blob/master/src/alloc.c#L6893
>
> Can you tell more about the use case where you needed this change?  A
> user-pointer holds a pointer to some unspecified data, and that data
> needs to be free'd when the user-pointer object is GC'ed; failure to
> do so will cause memory leaks.  When is the above incorrect, or gets
> in your way?
>
> Thanks.
>

--94eb2c06b69cec431c052c77ba3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">If the data is unspecified it doesn&#39;t *necessarily* ne=
ed to be freed. If I return a pointer to some global data then I need to cr=
eate a no-op finalizer just to please this GC code. In some cases I will be=
 managing memory a bit more manually and don&#39;t care to have Emacs doing=
 anything for me.<div><br></div><div>Thx.</div><div><br>Jess</div></div><di=
v class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Feb 19, 2016=
 at 3:33 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@gnu=
.org" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">&gt; From: Jess Balint &lt;<a href=3D"mailto:jbalint@gmai=
l.com">jbalint@HIDDEN</a>&gt;<br>
&gt; Date: Thu, 18 Feb 2016 15:52:55 -0600<br>
&gt;<br>
&gt; Dynamic modules are really cool so far, but I think finalizers should<=
br>
&gt; not be mandatory for user pointers (alloc.c):<br>
&gt;<br>
&gt; #ifdef HAVE_MODULES<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (mblk-&gt;marke=
rs[i].m.u_any.type =3D=3D Lisp_Misc_User_Ptr)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct Li=
sp_User_Ptr *uptr =3D &amp;mblk-&gt;markers[i].m.u_user_ptr;<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uptr-&gt;=
finalizer (uptr-&gt;p); &lt;----- should NULL-check first<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt; #endif<br>
&gt;<br>
&gt; c.f. <a href=3D"https://github.com/emacs-mirror/emacs/blob/master/src/=
alloc.c#L6893" rel=3D"noreferrer" target=3D"_blank">https://github.com/emac=
s-mirror/emacs/blob/master/src/alloc.c#L6893</a><br>
<br>
Can you tell more about the use case where you needed this change?=C2=A0 A<=
br>
user-pointer holds a pointer to some unspecified data, and that data<br>
needs to be free&#39;d when the user-pointer object is GC&#39;ed; failure t=
o<br>
do so will cause memory leaks.=C2=A0 When is the above incorrect, or gets<b=
r>
in your way?<br>
<br>
Thanks.<br>
</blockquote></div><br></div>

--94eb2c06b69cec431c052c77ba3e--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 24 Feb 2016 03:41:02 +0000
Resent-Message-ID: <handler.22737.B22737.145628523031225 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jess Balint <jbalint@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145628523031225
          (code B ref 22737); Wed, 24 Feb 2016 03:41:02 +0000
Received: (at 22737) by debbugs.gnu.org; 24 Feb 2016 03:40:30 +0000
Received: from localhost ([127.0.0.1]:42042 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aYQJS-00087Z-Bk
	for submit <at> debbugs.gnu.org; Tue, 23 Feb 2016 22:40:30 -0500
Received: from eggs.gnu.org ([208.118.235.92]:44549)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <eliz@HIDDEN>) id 1aYQJR-00087N-Nz
 for 22737 <at> debbugs.gnu.org; Tue, 23 Feb 2016 22:40:29 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1aYQJH-0004gV-MN
 for 22737 <at> debbugs.gnu.org; Tue, 23 Feb 2016 22:40:24 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59362)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1aYQJH-0004gH-K5; Tue, 23 Feb 2016 22:40:19 -0500
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3254
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1aYQJG-0002dl-1r; Tue, 23 Feb 2016 22:40:18 -0500
Date: Wed, 24 Feb 2016 05:40:13 +0200
Message-Id: <83fuwiixnm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 (message from Jess Balint on Tue, 23 Feb 2016 16:47:12 -0600)
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Tue, 23 Feb 2016 16:47:12 -0600
> From: Jess Balint <jbalint@HIDDEN>
> Cc: 22737 <at> debbugs.gnu.org
> 
> If the data is unspecified it doesn't *necessarily* need to be freed. If I return a pointer to some global data then
> I need to create a no-op finalizer just to please this GC code. In some cases I will be managing memory a bit
> more manually and don't care to have Emacs doing anything for me.

I don't think I follow.  How can you manage memory manually when Emacs
does GC whenever it feels like it?  The memory of the objects it GCs
will simply be leaked if you don't have a finalizer.

Can you describe a specific use case where a finalizer would not be
needed?

Thanks.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 16:18:01 +0000
Resent-Message-ID: <handler.22737.B22737.145650345329803 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145650345329803
          (code B ref 22737); Fri, 26 Feb 2016 16:18:01 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 16:17:33 +0000
Received: from localhost ([127.0.0.1]:47823 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZL5B-0007kc-Jm
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 11:17:33 -0500
Received: from mail-ig0-f169.google.com ([209.85.213.169]:36297)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aZL5A-0007kP-30
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 11:17:32 -0500
Received: by mail-ig0-f169.google.com with SMTP id xg9so37636796igb.1
 for <22737 <at> debbugs.gnu.org>; Fri, 26 Feb 2016 08:17:32 -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=vk1aqQwZQplQ+eJz/rL6i90USMAtDY7EbYyhEIW+Ej8=;
 b=E/ts5G6ihT5wnLHRW6TbQBzIrrHn2301sQ11jZ9oLDyLCFncA5dhEfTcCoNPreKz0j
 lDn3I964w7uV/xYzXkPEZrEUC0Wkar8eo0k1Tv1EOFRBNg3zM+9pzjXLc4tXnOEzYqcy
 t60WojnpBvE+FP7r4iIVvZbLs9nSDZGvTBVpBE7OViBcWbS1zTNeJu1t5VvhHt3PcIKQ
 OlVTpImUHGYjWSUWUXx0r+NrZw8l4zS6n4bVOHRlE4UOsY0PMnncVDemYolCgVpZQAMl
 TM9kfOO3vxrKdGvSZnE7JoZZdPwitL9ZNy/APAAtHKPZb//SfjDWDFWNE7Z3nHqCI1e6
 xhYg==
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=vk1aqQwZQplQ+eJz/rL6i90USMAtDY7EbYyhEIW+Ej8=;
 b=bjZDsEd0qRROqQH6N9qMdSAJARHX3QeS15ejtPIQY+84zV3SYwBfqxgUIZvEm3Npm3
 3acjgoxR7AEcyuIYxUoTwRHlmASpoyTAHSbJkNOcArcXtCiEPd3OTiwcivuUrYSnl9lY
 YPuifoQPCw8o+AylJnWAOKFlup0KdAsnLtMPIMSf3WREM5sZY7QdY+GYU3X7uQYFgJgL
 cpQCUbeuyLafgCvfnOoa+znOejmbIyFV6Uz1q/NscllhewLSm/tHVrmEZOAQT9dNsxXf
 1RTGyXctLd75PhUksx3aZVGnNIqWgc/GtiZSNfkPnKjKUrlrOsPZ0Vr5Cp/wTLoEh9v9
 HZ9w==
X-Gm-Message-State: AD7BkJLgo21kvGtiQ20Gntbu68kt1Ckz3aZ+RuoAPfbLnYTyazYAUoVp74Nt5Nb8JNjjVCCyiZJh8AEolWWnJA==
MIME-Version: 1.0
X-Received: by 10.50.225.106 with SMTP id rj10mr3001081igc.23.1456503446324;
 Fri, 26 Feb 2016 08:17:26 -0800 (PST)
Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 08:17:26 -0800 (PST)
In-Reply-To: <83fuwiixnm.fsf@HIDDEN>
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
Date: Fri, 26 Feb 2016 10:17:26 -0600
Message-ID: <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
From: Jess Balint <jbalint@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c39aa6884fdd052caea2f1
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c39aa6884fdd052caea2f1
Content-Type: text/plain; charset=UTF-8

Situation #1 - globals:

I have pointers to data that are global (not on the heap). I return these
pointers from module functions so that they may be used as parameters to
other module function calls. These pointers should *never* be freed. In
this case I need to supply a no-op finalizer when creating the user pointer.

Situation #2 - manual memory management:

I have heap-allocated structures whose memory should not be managed by
Emacs. I may return pointers to this data one or many times from module
calls. The data should be freed only when explicitly requested. I may
return many user pointers to the same heap-allocated structure. Even when
all these are freed by Emacs, I still retain a pointer in my module which
may be returned in a future module call. Again, I'm required to supply a
no-op finalizer when creating these user pointers.

Thanks.

Jess


On Tue, Feb 23, 2016 at 9:40 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Tue, 23 Feb 2016 16:47:12 -0600
> > From: Jess Balint <jbalint@HIDDEN>
> > Cc: 22737 <at> debbugs.gnu.org
> >
> > If the data is unspecified it doesn't *necessarily* need to be freed. If
> I return a pointer to some global data then
> > I need to create a no-op finalizer just to please this GC code. In some
> cases I will be managing memory a bit
> > more manually and don't care to have Emacs doing anything for me.
>
> I don't think I follow.  How can you manage memory manually when Emacs
> does GC whenever it feels like it?  The memory of the objects it GCs
> will simply be leaked if you don't have a finalizer.
>
> Can you describe a specific use case where a finalizer would not be
> needed?
>
> Thanks.
>

--001a11c39aa6884fdd052caea2f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Situation #1 - globals:<div><br></div><div>I have pointers=
 to data that are global (not on the heap). I return these pointers from mo=
dule functions so that they may be used as parameters to other module funct=
ion calls. These pointers should *never* be freed. In this case I need to s=
upply a no-op finalizer when creating the user pointer.</div><div><br></div=
><div>Situation #2 - manual memory management:</div><div><br></div><div>I h=
ave heap-allocated structures whose memory should not be managed by Emacs. =
I may return pointers to this data one or many times from module calls. The=
 data should be freed only when explicitly requested. I may return many use=
r pointers to the same heap-allocated structure. Even when all these are fr=
eed by Emacs, I still retain a pointer in my module which may be returned i=
n a future module call. Again, I&#39;m required to supply a no-op finalizer=
 when creating these user pointers.</div><div><br></div><div>Thanks.</div><=
div><br></div><div>Jess</div><div><br></div></div><div class=3D"gmail_extra=
"><br><div class=3D"gmail_quote">On Tue, Feb 23, 2016 at 9:40 PM, Eli Zaret=
skii <span dir=3D"ltr">&lt;<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank=
">eliz@HIDDEN</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">&gt;=
 Date: Tue, 23 Feb 2016 16:47:12 -0600<br>
&gt; From: Jess Balint &lt;<a href=3D"mailto:jbalint@HIDDEN">jbalint@gma=
il.com</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:22737 <at> debbugs.gnu.org">22737 <at> debbugs.gnu.org</a>=
<br>
<span class=3D"">&gt;<br>
&gt; If the data is unspecified it doesn&#39;t *necessarily* need to be fre=
ed. If I return a pointer to some global data then<br>
&gt; I need to create a no-op finalizer just to please this GC code. In som=
e cases I will be managing memory a bit<br>
&gt; more manually and don&#39;t care to have Emacs doing anything for me.<=
br>
<br>
</span>I don&#39;t think I follow.=C2=A0 How can you manage memory manually=
 when Emacs<br>
does GC whenever it feels like it?=C2=A0 The memory of the objects it GCs<b=
r>
will simply be leaked if you don&#39;t have a finalizer.<br>
<br>
Can you describe a specific use case where a finalizer would not be<br>
needed?<br>
<br>
Thanks.<br>
</blockquote></div><br></div>

--001a11c39aa6884fdd052caea2f1--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 18:38:02 +0000
Resent-Message-ID: <handler.22737.B22737.145651182210366 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jess Balint <jbalint@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145651182210366
          (code B ref 22737); Fri, 26 Feb 2016 18:38:02 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 18:37:02 +0000
Received: from localhost ([127.0.0.1]:47882 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZNGA-0002h8-8M
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 13:37:02 -0500
Received: from eggs.gnu.org ([208.118.235.92]:43052)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <eliz@HIDDEN>) id 1aZNG9-0002ge-3B
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 13:37:01 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1aZNFz-0002j1-Au
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 13:36:56 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:54166)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1aZNFz-0002ix-7J; Fri, 26 Feb 2016 13:36:51 -0500
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3387
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1aZNFy-0006Ps-Fi; Fri, 26 Feb 2016 13:36:50 -0500
Date: Fri, 26 Feb 2016 20:36:34 +0200
Message-Id: <83vb5bco99.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 (message from Jess Balint on Fri, 26 Feb 2016 10:17:26 -0600)
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Fri, 26 Feb 2016 10:17:26 -0600
> From: Jess Balint <jbalint@HIDDEN>
> Cc: 22737 <at> debbugs.gnu.org
> 
> Situation #1 - globals:
> 
> I have pointers to data that are global (not on the heap). I return these pointers from module functions so that
> they may be used as parameters to other module function calls. These pointers should *never* be freed. In
> this case I need to supply a no-op finalizer when creating the user pointer.
> 
> Situation #2 - manual memory management:
> 
> I have heap-allocated structures whose memory should not be managed by Emacs. I may return pointers to
> this data one or many times from module calls. The data should be freed only when explicitly requested. I may
> return many user pointers to the same heap-allocated structure. Even when all these are freed by Emacs, I
> still retain a pointer in my module which may be returned in a future module call. Again, I'm required to supply
> a no-op finalizer when creating these user pointers.

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?




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 18:54:02 +0000
Resent-Message-ID: <handler.22737.B22737.145651280811787 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: 22737 <at> debbugs.gnu.org
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145651280811787
          (code B ref 22737); Fri, 26 Feb 2016 18:54:02 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 18:53:28 +0000
Received: from localhost ([127.0.0.1]:47886 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZNW3-000343-OE
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 13:53:28 -0500
Received: from mail-ig0-f172.google.com ([209.85.213.172]:36720)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aZNW2-00033n-7r
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 13:53:26 -0500
Received: by mail-ig0-f172.google.com with SMTP id xg9so40479214igb.1
 for <22737 <at> debbugs.gnu.org>; Fri, 26 Feb 2016 10:53:26 -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=hkxOu7OnKSMABbAYBdd98YSZW9RmXFQYO4n/4VtrU3o=;
 b=dUshf9gmjx0WTcZt1ygEBMB/ZjYJkotkw0yklQj1GsUGMktcfxofdlwjCx/XsQ4I5E
 CKHX6ptE+3g9yc7xAIwtAA2CLzIzYF+bpCP2EBdiqP2Z0GkcOeH10hOzbauNeaAgzND1
 kgK8XikezT+yB445jsGyqX2uTo+eKKMWXO7Ry8OZLBlE5yCLdBtPG/k00nZpUpjIagmk
 ugmliw5JfK/msEn7wOhAppFwlUTgdOFczBmfm3sn35MPg5xFQPR1kPeRWwtii1x2xlAJ
 HqStKUec8qd0G95NQLUJKjUiKFcuUUVXc2WxvPi8luHWNWMOysAYim3OBx9sFbYnVxJs
 UZ0A==
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=hkxOu7OnKSMABbAYBdd98YSZW9RmXFQYO4n/4VtrU3o=;
 b=S7tKAKLb0qNsrNEsPRmV1/FDiAeN7jDLWan1TxyMZtXZRn9zicBShlweXIgg4lwRlM
 raZTbOSAcmvKR8IJ24lPeZSD1ITuOgpOYbgh9zIBz7FbVkkQkAY0i5RYj4EbQlwQpU31
 V+Qp4zdxaMwOFLPovslDz/ymYLX4qhZtjZCGdpexMwvmpleRGUQy7OPeD6tWWLfNiq/z
 AG9ixn7p13T9upWDyu4Pyv8xLWN77iksM9c6OKU8GGNFBm4DK4KO+lHxqXjXZbMgHd+a
 DfMkbDvoRLxstZZ+rjiqBnctfO9fQWcbmWWi6KkAIxRRJnT8lei/68lvorORtAGrBxPa
 l9Sw==
X-Gm-Message-State: AD7BkJIU1ItP3iOP8lQXXdpRCDDZZWHWEEW1DsjlL/5GiqUY3Nmwvfdt1fp2k0ze7alUMjrA+8XSaGRNOZhdsQ==
MIME-Version: 1.0
X-Received: by 10.50.183.2 with SMTP id ei2mr4133688igc.57.1456512800455; Fri,
 26 Feb 2016 10:53:20 -0800 (PST)
Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 10:53:20 -0800 (PST)
In-Reply-To: <83vb5bco99.fsf@HIDDEN>
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 <83vb5bco99.fsf@HIDDEN>
Date: Fri, 26 Feb 2016 12:53:20 -0600
Message-ID: <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
From: Jess Balint <jbalint@HIDDEN>
Content-Type: multipart/alternative; boundary=001a113319da150574052cb0d053
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a113319da150574052cb0d053
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 26, 2016 at 12:36 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Fri, 26 Feb 2016 10:17:26 -0600
> > From: Jess Balint <jbalint@HIDDEN>
> > Cc: 22737 <at> debbugs.gnu.org
> >
> > Situation #1 - globals:
> >
> > I have pointers to data that are global (not on the heap). I return
> these pointers from module functions so that
> > they may be used as parameters to other module function calls. These
> pointers should *never* be freed. In
> > this case I need to supply a no-op finalizer when creating the user
> pointer.
> >
> > Situation #2 - manual memory management:
> >
> > I have heap-allocated structures whose memory should not be managed by
> Emacs. I may return pointers to
> > this data one or many times from module calls. The data should be freed
> only when explicitly requested. I may
> > return many user pointers to the same heap-allocated structure. Even
> when all these are freed by Emacs, I
> > still retain a pointer in my module which may be returned in a future
> module call. Again, I'm required to supply
> > a no-op finalizer when creating these user pointers.
>
> 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".

Jess

--001a113319da150574052cb0d053
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 26, 2016 at 12:36 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=
=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrot=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">&gt; Date: Fri, 26 Feb 2016 10:17:26 -=
0600<br>
<span class=3D"">&gt; From: Jess Balint &lt;<a href=3D"mailto:jbalint@gmail=
.com">jbalint@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:22737 <at> debbugs.gnu.org">22737 <at> debbugs.gnu.org</a>=
<br>
&gt;<br>
</span><span class=3D"">&gt; Situation #1 - globals:<br>
&gt;<br>
&gt; I have pointers to data that are global (not on the heap). I return th=
ese pointers from module functions so that<br>
&gt; they may be used as parameters to other module function calls. These p=
ointers should *never* be freed. In<br>
&gt; this case I need to supply a no-op finalizer when creating the user po=
inter.<br>
&gt;<br>
&gt; Situation #2 - manual memory management:<br>
&gt;<br>
&gt; I have heap-allocated structures whose memory should not be managed by=
 Emacs. I may return pointers to<br>
&gt; this data one or many times from module calls. The data should be free=
d only when explicitly requested. I may<br>
&gt; return many user pointers to the same heap-allocated structure. Even w=
hen all these are freed by Emacs, I<br>
&gt; still retain a pointer in my module which may be returned in a future =
module call. Again, I&#39;m required to supply<br>
&gt; a no-op finalizer when creating these user pointers.<br>
<br>
</span>What will happen if such objects are exposed to Lisp, copied or<br>
assigned to other Lisp variables, etc.?=C2=A0 Won&#39;t this cause all kind=
s of<br>
trouble, like modifying one such object will magically modify several<br>
others, which share its storage?<br>
</blockquote></div><br></div><div class=3D"gmail_extra">This is how C code =
works. If you return a pointer from a function, you may have to free that p=
ointer yourself or you may not. You may get the same pointer back from mult=
iple calls to the same function. If you use the pointer after it&#39;s been=
 freed, it&#39;s your problem. You need to agree with the owner of the poin=
ter how the memory is to be managed. With pointers, modifications to the un=
derlying data are visible by all who have a pointer to the data. I wouldn&#=
39;t call this &quot;magically modifying others&quot;.</div><div class=3D"g=
mail_extra"><br></div><div class=3D"gmail_extra">Jess</div></div>

--001a113319da150574052cb0d053--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 21:34:02 +0000
Resent-Message-ID: <handler.22737.B22737.145652242132347 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jess Balint <jbalint@HIDDEN>, Daniel Colascione <dancol@HIDDEN>, John Wiegley <johnw@HIDDEN> 
Cc: 22737 <at> debbugs.gnu.org
Reply-To: Eli Zaretskii <eliz@HIDDEN>
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145652242132347
          (code B ref 22737); Fri, 26 Feb 2016 21:34:02 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 21:33:41 +0000
Received: from localhost ([127.0.0.1]:47926 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZQ16-0008Pe-NW
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:33:40 -0500
Received: from eggs.gnu.org ([208.118.235.92]:54516)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <eliz@HIDDEN>) id 1aZQ15-0008PS-4i
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:33:40 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <eliz@HIDDEN>) id 1aZQ0z-0004mh-18
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:33:33 -0500
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.0 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD
 autolearn=disabled version=3.3.2
Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56957)
 by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <eliz@HIDDEN>)
 id 1aZQ0u-0004lL-Dr; Fri, 26 Feb 2016 16:33:28 -0500
Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3541
 helo=home-c4e4a596f7)
 by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128)
 (Exim 4.82) (envelope-from <eliz@HIDDEN>)
 id 1aZQ0t-0006aP-Kj; Fri, 26 Feb 2016 16:33:28 -0500
Date: Fri, 26 Feb 2016 23:33:07 +0200
Message-Id: <83twkvcg30.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-reply-to: <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
 (message from Jess Balint on Fri, 26 Feb 2016 12:53:20 -0600)
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 <83vb5bco99.fsf@HIDDEN>
 <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
X-Received-From: 2001:4830:134:3::e
X-Spam-Score: -5.0 (-----)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.0 (-----)

> Date: Fri, 26 Feb 2016 12:53:20 -0600
> From: Jess Balint <jbalint@HIDDEN>
> Cc: 22737 <at> 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.




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 21:52:01 +0000
Resent-Message-ID: <handler.22737.B22737.14565235101484 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Daniel Colascione <dancol@HIDDEN>, 22737 <at> debbugs.gnu.org, John Wiegley <johnw@HIDDEN>
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.14565235101484
          (code B ref 22737); Fri, 26 Feb 2016 21:52:01 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 21:51:50 +0000
Received: from localhost ([127.0.0.1]:47931 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZQIg-0000Ns-BL
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:51:50 -0500
Received: from mail-io0-f172.google.com ([209.85.223.172]:36225)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aZQIf-0000Nf-75
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:51:49 -0500
Received: by mail-io0-f172.google.com with SMTP id l127so135514844iof.3
 for <22737 <at> debbugs.gnu.org>; Fri, 26 Feb 2016 13:51:49 -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=LsV8lgF8wHNnhW5+7m1hTWKli0IHfNqBnrz0GrjU/KI=;
 b=q3OlaOz/RLptHP2Toz5h9ZVx7LcjyJKSt8iQFIixwMi2M4KilobdV7LAxKSx8T979d
 9qqjo3CiZ78DmNkHF4P81kvAvk6CbvbkQHU2r08ODcASiwe4XU6LSnyKGJEG17BXJPnu
 eH2hXgZzY5URt9XwAA8YyEWl5ar/9WlbLHLeac3+5TAMo/NotjVZ8etFneceVkw1uNLh
 ptreRzhJxOk8Kf9UIosWVGc+KdOdsKADAJz2bB9OpnfHkNiE1W3aPL74us8NGiKeNlxw
 BiZM2IiQ5Wxvo33mREGE/q4U8gpR9R86c2/Lcc9c5tEikJ2AsV6HLuHGkrw4P0xc4TUr
 XJFA==
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=LsV8lgF8wHNnhW5+7m1hTWKli0IHfNqBnrz0GrjU/KI=;
 b=Hlzs7EUK4takziZ68pbf9LqoKR2uwFk1Qf8qCdgYRgGgy8Kw7xlfOqKvogBDv3/szy
 0SSD7jK72nNZaTplwLQmH7mEVPGJe6nXHfgQ1lZOwpCUM8MBVYoLVs0QXvoytGYo8oYy
 ANRMJGZRw6vknc/e9GLYcnn1pfM9QM4tRHYU7zIZisT4V1QqUnf0GnGAI5zuvpL8Q3BX
 2u/ymEGI4FrtvXh3nlEmjFXkibwdro91kdeNM9Q4DfCuVCDIix2zkFo41Z7oxHYpEDrE
 S96hzwrnZJvvHv0W25kgMeZa6WKU2ke46ST5k5zQrMc5dO/BhSTvwmF8bHV7G/LpEEp1
 MR8Q==
X-Gm-Message-State: AG10YOTsXL2o5BplacuIi8wbIy1N3TF7RZ77WAgwX4H+u7P7wbc9sN0Oo9JTJpMKo7YbCpq/Fs3qDukDQ4vcOA==
MIME-Version: 1.0
X-Received: by 10.107.135.212 with SMTP id r81mr9708376ioi.59.1456523503493;
 Fri, 26 Feb 2016 13:51:43 -0800 (PST)
Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 13:51:43 -0800 (PST)
In-Reply-To: <83twkvcg30.fsf@HIDDEN>
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 <83vb5bco99.fsf@HIDDEN>
 <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
 <83twkvcg30.fsf@HIDDEN>
Date: Fri, 26 Feb 2016 15:51:43 -0600
Message-ID: <CA+fD2U3SVA2H20RFx3H0jvO9WKnV9crhH6ipaPW0QyA7cDnyyQ@HIDDEN>
From: Jess Balint <jbalint@HIDDEN>
Content-Type: multipart/alternative; boundary=001a113ec85a088ac9052cb34eb7
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a113ec85a088ac9052cb34eb7
Content-Type: text/plain; charset=UTF-8

On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > Date: Fri, 26 Feb 2016 12:53:20 -0600
> > From: Jess Balint <jbalint@HIDDEN>
> > Cc: 22737 <at> 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.

Thanks.

Jess

--001a113ec85a088ac9052cb34eb7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D=
"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex">&gt; Date: Fri, 26 Feb 2016 12:53:20 -060=
0<br>
<span class=3D"">&gt; From: Jess Balint &lt;<a href=3D"mailto:jbalint@gmail=
.com">jbalint@HIDDEN</a>&gt;<br>
&gt; Cc: <a href=3D"mailto:22737 <at> debbugs.gnu.org">22737 <at> debbugs.gnu.org</a>=
<br>
&gt;<br>
</span><span class=3D"">&gt;=C2=A0 What will happen if such objects are exp=
osed to Lisp, copied or<br>
&gt;=C2=A0 assigned to other Lisp variables, etc.? Won&#39;t this cause all=
 kinds of<br>
&gt;=C2=A0 trouble, like modifying one such object will magically modify se=
veral<br>
&gt;=C2=A0 others, which share its storage?<br>
&gt;<br>
&gt; This is how C code works. If you return a pointer from a function, you=
 may have to free that pointer yourself or<br>
&gt; you may not. You may get the same pointer back from multiple calls to =
the same function. If you use the<br>
&gt; pointer after it&#39;s been freed, it&#39;s your problem. You need to =
agree with the owner of the pointer how the<br>
&gt; memory is to be managed. With pointers, modifications to the underlyin=
g data are visible by all who have a<br>
&gt; pointer to the data. I wouldn&#39;t call this &quot;magically modifyin=
g others&quot;.<br>
<br>
</span>In C, yes.=C2=A0 But we are talking about Lisp objects here.<br>
<br>
Am I the only one who is uneasy with supporting such Lisp objects?=C2=A0 If=
<br>
so, I will shut up and install the changes.=C2=A0 Daniel, John, what&#39;s =
your<br>
opinion on this?<br>
<br>
Thanks.<br>
</blockquote></div><br></div><div class=3D"gmail_extra">All I&#39;m asking =
for is to allow the code to accept a NULL finalizer. This means no finalize=
r will be called. It&#39;s a clear and simple semantic. Upside is that I (a=
nd others who do not want Emacs to free their pointers) will not have to cr=
eate a no-op function unnecessarily to supply a finalizer to Emacs.</div><d=
iv class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Thanks.</div>=
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jess</div><=
/div>

--001a113ec85a088ac9052cb34eb7--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Daniel Colascione <dancol@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 26 Feb 2016 21:56:02 +0000
Resent-Message-ID: <handler.22737.B22737.14565237111827 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Jess Balint <jbalint@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>
Cc: John Wiegley <johnw@HIDDEN>, 22737 <at> debbugs.gnu.org
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.14565237111827
          (code B ref 22737); Fri, 26 Feb 2016 21:56:02 +0000
Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 21:55:11 +0000
Received: from localhost ([127.0.0.1]:47939 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aZQLv-0000TO-4s
	for submit <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:55:11 -0500
Received: from dancol.org ([96.126.100.184]:56282)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <dancol@HIDDEN>) id 1aZQLt-0000TG-BX
 for 22737 <at> debbugs.gnu.org; Fri, 26 Feb 2016 16:55:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
 s=x; 
 h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject;
 bh=HKvUpqFSLIkEEAoX4PsoJI5fj9xs3BuN28rJm6+y35A=; 
 b=Sjw3tOaJpnuHc7o1P48E97O2WSFl2qLZV4cAXolxTILdlz66yJIWfVR9rvX2XiammKrfD26KWGJhM3dG4SMO39D0RKX2Zyntka8T2zQui1Y6L583NoEx8cSXEYt7mmukB58v/fo24kdpwqHMYpE55WSEz5FwBUUIGake0FINAyHd1cFo6dl3e6GchXTrjfrFXxtGH60c1B0BIA3JYrAIMTe6R3GZ89KBMyDDPjjs38kRxFHclVGVu9wcLIU2zqw2BHYUDGl2zosWrEfgHHKJJImonsJxIUwM749qNFJWHkqDx0ki5y+6Uxl557YTvODgBk2OBWQvbnz6ONrlarB/bw==;
Received: from [2620:10d:c090:200::5:2766]
 (helo=[IPv6:2620:10d:c083:10fb:2ab2:bdff:fe1c:db58])
 by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84) (envelope-from <dancol@HIDDEN>)
 id 1aZQLr-0001xu-9i; Fri, 26 Feb 2016 13:55:07 -0800
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 <83vb5bco99.fsf@HIDDEN>
 <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
 <83twkvcg30.fsf@HIDDEN>
 <CA+fD2U3SVA2H20RFx3H0jvO9WKnV9crhH6ipaPW0QyA7cDnyyQ@HIDDEN>
From: Daniel Colascione <dancol@HIDDEN>
Message-ID: <56D0C9B4.8070105@HIDDEN>
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
MIME-Version: 1.0
In-Reply-To: <CA+fD2U3SVA2H20RFx3H0jvO9WKnV9crhH6ipaPW0QyA7cDnyyQ@HIDDEN>
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="qVOuXh82dX4cCBfMKswnNjXIqENlmlh79"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--qVOuXh82dX4cCBfMKswnNjXIqENlmlh79
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 02/26/2016 01:51 PM, Jess Balint wrote:
> On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <eliz@HIDDEN
> <mailto:eliz@HIDDEN>> wrote:
>=20
>     > Date: Fri, 26 Feb 2016 12:53:20 -0600
>     > From: Jess Balint <jbalint@HIDDEN <mailto:jbalint@HIDDEN>>
>     > Cc: 22737 <at> debbugs.gnu.org <mailto:22737 <at> 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 kin=
ds of
>     >  trouble, like modifying one such object will magically modify se=
veral
>     >  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 call=
s to the same function. If you use the
>     > pointer after it's been freed, it's your problem. You need to agr=
ee with the owner of the pointer how the
>     > memory is to be managed. With pointers, modifications to the unde=
rlying data are visible by all who have a
>     > pointer to the data. I wouldn't call this "magically modifying ot=
hers".
>=20
>     In C, yes.  But we are talking about Lisp objects here.
>=20
>     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 y=
our
>     opinion on this?
>=20
>     Thanks.
>=20
>=20
> All I'm asking for is to allow the code to accept a NULL finalizer. Thi=
s
> 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.


--qVOuXh82dX4cCBfMKswnNjXIqENlmlh79
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJW0Mm0AAoJEN4WImmbpWBlRSMQAJ6naQZeVhoJ2DqW3TV5XvJ4
jeflLRu0WCQVehT6cLGYsY/7hBXSxFpi7V1h80liK/vmedfwKGweceVyz4duQ0FX
IHhLtzKn0pnQpEQ6N9/gRpIawhkXTsiqGtpNdOyQTJWCCYYi04Bc1FHjgl4rD1J8
m5xZ2jnr931+hB7URXCUG3Kb1hIGqidvtQ5rYCxz3agd0eMGsIVXqLqBjHdkhgAQ
k0vtSDoVejxePGuq9sIwIFi8Q0sM0prxt4r7iibH1CIiD1G6IDYXNfjYqB1aqFby
kOFakT0Vf8a6GmQcVdLpl1tlgxCsGi40iLZGmMN3D+1HqlxZGkdaLMJBgcE3EIqI
ETdd6nJYbkC2PHObhK4SnzS5pEJkcsNxlgtMG/YTefrtun0BMNfA6rJxnIZGtsgp
b3h7nyRGCZPLhm5Pqw4kQSCF+957tMnT0ENHxUpQmT3v6IrvXcbVlSUN7K1ExVrI
CXRB/9KTFN5zdGE9KUUWRLjOBiZFR27nDZidWwSznVA5iNZC573qSo/3Zut+hNlW
UJrjs8yOO/YIOOE9vTynkm+ze0AYuvBHSbOLPWwO4krwodZfWRoy2Q19Zj2moshd
1452Q+xThT9PFLHolM+9SH01FoRHiIGxFm6Gbj9fEsg3BbYOdJYfPzwzgM5P1OOb
WN/gfSqe8su/W3E/52I2
=o/Ye
-----END PGP SIGNATURE-----

--qVOuXh82dX4cCBfMKswnNjXIqENlmlh79--




Message sent to bug-gnu-emacs@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
Resent-From: Jess Balint <jbalint@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 29 Feb 2016 20:29:01 +0000
Resent-Message-ID: <handler.22737.B22737.145677770122212 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 22737
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Daniel Colascione <dancol@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, John Wiegley <johnw@HIDDEN>, 22737 <at> debbugs.gnu.org
Received: via spool by 22737-submit <at> debbugs.gnu.org id=B22737.145677770122212
          (code B ref 22737); Mon, 29 Feb 2016 20:29:01 +0000
Received: (at 22737) by debbugs.gnu.org; 29 Feb 2016 20:28:21 +0000
Received: from localhost ([127.0.0.1]:54108 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1aaUQW-0005mC-UY
	for submit <at> debbugs.gnu.org; Mon, 29 Feb 2016 15:28:21 -0500
Received: from mail-ig0-f178.google.com ([209.85.213.178]:36943)
 by debbugs.gnu.org with esmtp (Exim 4.84)
 (envelope-from <jbalint@HIDDEN>) id 1aaUQV-0005m0-P0
 for 22737 <at> debbugs.gnu.org; Mon, 29 Feb 2016 15:28:20 -0500
Received: by mail-ig0-f178.google.com with SMTP id z8so3458999ige.0
 for <22737 <at> 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==
MIME-Version: 1.0
X-Received: by 10.50.117.103 with SMTP id kd7mr2240601igb.57.1456777694230;
 Mon, 29 Feb 2016 12:28:14 -0800 (PST)
Received: by 10.64.223.105 with HTTP; Mon, 29 Feb 2016 12:28:14 -0800 (PST)
In-Reply-To: <56D0C9B4.8070105@HIDDEN>
References: <87a8mxsn2g.fsf@HIDDEN> <83lh6hrqm4.fsf@HIDDEN>
 <CA+fD2U34Cm0OCLD3uMeTmaXGD4cZG1xFX27hj0jCTG62hKq1_Q@HIDDEN>
 <83fuwiixnm.fsf@HIDDEN>
 <CA+fD2U2+tLipoUUw4wNNWm7aGcuq_+S6pJ2Z0bAJbFaSM-da-A@HIDDEN>
 <83vb5bco99.fsf@HIDDEN>
 <CA+fD2U3tELid_C5yFEhn_TQDLS7+RbR2O471-=wm48dxTHiaXA@HIDDEN>
 <83twkvcg30.fsf@HIDDEN>
 <CA+fD2U3SVA2H20RFx3H0jvO9WKnV9crhH6ipaPW0QyA7cDnyyQ@HIDDEN>
 <56D0C9B4.8070105@HIDDEN>
Date: Mon, 29 Feb 2016 14:28:14 -0600
Message-ID: <CA+fD2U2_S+g=DHc_2SMVz+wew+e8sk9ygUE2cu67yyFg88GTEw@HIDDEN>
From: Jess Balint <jbalint@HIDDEN>
Content-Type: multipart/alternative; boundary=089e013a084cfb3fb0052cee7ce6
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e013a084cfb3fb0052cee7ce6
Content-Type: text/plain; charset=UTF-8

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

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Feb 26, 2016 at 3:55 PM, Daniel Colascione <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:dancol@HIDDEN" target=3D"_blank">dancol@HIDDEN</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 02/26/2=
016 01:51 PM, Jess Balint wrote:<br>
&gt; On Fri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii &lt;<a href=3D"mailto:e=
liz@HIDDEN">eliz@HIDDEN</a><br>
</span><span class=3D"">&gt; &lt;mailto:<a href=3D"mailto:eliz@HIDDEN">eli=
z@HIDDEN</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; Date: Fri, 26 Feb 2016 12:53:20 -0600<br>
</span>&gt;=C2=A0 =C2=A0 =C2=A0&gt; From: Jess Balint &lt;<a href=3D"mailto=
:jbalint@HIDDEN">jbalint@HIDDEN</a> &lt;mailto:<a href=3D"mailto:jbal=
int@HIDDEN">jbalint@HIDDEN</a>&gt;&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; Cc: <a href=3D"mailto:22737 <at> debbugs.gnu.org">2=
2737 <at> debbugs.gnu.org</a> &lt;mailto:<a href=3D"mailto:22737 <at> debbugs.gnu.org=
">22737 <at> debbugs.gnu.org</a>&gt;<br>
<span class=3D"">&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 What will happen if such objects are exp=
osed to Lisp, copied or<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 assigned to other Lisp variables, etc.? =
Won&#39;t this cause all kinds of<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 trouble, like modifying one such object =
will magically modify several<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;=C2=A0 others, which share its storage?<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; This is how C code works. If you return a poin=
ter from a function, you may have to free that pointer yourself or<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; you may not. You may get the same pointer back=
 from multiple calls to the same function. If you use the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; pointer after it&#39;s been freed, it&#39;s yo=
ur problem. You need to agree with the owner of the pointer how the<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; memory is to be managed. With pointers, modifi=
cations to the underlying data are visible by all who have a<br>
&gt;=C2=A0 =C2=A0 =C2=A0&gt; pointer to the data. I wouldn&#39;t call this =
&quot;magically modifying others&quot;.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0In C, yes.=C2=A0 But we are talking about Lisp obje=
cts here.<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Am I the only one who is uneasy with supporting suc=
h Lisp objects?=C2=A0 If<br>
&gt;=C2=A0 =C2=A0 =C2=A0so, I will shut up and install the changes.=C2=A0 D=
aniel, John, what&#39;s your<br>
&gt;=C2=A0 =C2=A0 =C2=A0opinion on this?<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0Thanks.<br>
&gt;<br>
&gt;<br>
&gt; All I&#39;m asking for is to allow the code to accept a NULL finalizer=
. This<br>
&gt; means no finalizer will be called. It&#39;s a clear and simple semanti=
c.<br>
&gt; Upside is that I (and others who do not want Emacs to free their<br>
&gt; pointers) will not have to create a no-op function unnecessarily to<br=
>
&gt; supply a finalizer to Emacs.<br>
<br>
</span>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<br>
it&#39;s more important to discourage memory leaks and simplify the<br>
semantics of the finalizer parameter than to make this rare (I think)<br>
use case slightly easier for module implementors.</blockquote><div>=C2=A0</=
div><div>Ok, I can respect that. I don&#39;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.</div><div><br></div><div>Jess=
</div></div><br></div></div>

--089e013a084cfb3fb0052cee7ce6--




Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 4 Jun 2016 19:53:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jun 04 15:53:00 2016
Received: from localhost ([127.0.0.1]:54635 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1b9Hcy-0001mK-2G
	for submit <at> debbugs.gnu.org; Sat, 04 Jun 2016 15:53:00 -0400
Received: from mail-oi0-f51.google.com ([209.85.218.51]:35061)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1b9Hcw-0001m8-Ks
 for control <at> debbugs.gnu.org; Sat, 04 Jun 2016 15:52:58 -0400
Received: by mail-oi0-f51.google.com with SMTP id w184so174272445oiw.2
 for <control <at> debbugs.gnu.org>; Sat, 04 Jun 2016 12:52:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to;
 bh=b5K1UvwG0dVWwWR6/iylRDxhfgPgVva6jKIVVo6IQDo=;
 b=xZuKeZGSVR5nX54aNNYAHG8t6oaXfgfYWKudYbGExLq7wCEYsMJvvG+JW0d9Wqk0Df
 wv7+iGvBj53jg9HDHqq/WM+ef7l1d+ViymQMJ4VN9o1KaT/m3+h7QnTgGx3xePW6Ecxm
 yH58IOTGDTt9EpVKzKvyPdtuoikDMAnyuIqepBPUQ1606aLV9GaRTMyl65G0ptCgwMU6
 2XsBaYy5LUFzBHO2qbkaEM5DgD07ezcJdMwOoeOlrntBCKKUUQNgOSpWBv4RY24au67l
 tY7nPgOHOdCqQWPvlaYFeQUhIHnHxHQZrf1Xx8qxOzAY1N+zDgEGXCRKP+1xmhuAvjsR
 6A7w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:sender:from:date:message-id:subject
 :to; bh=b5K1UvwG0dVWwWR6/iylRDxhfgPgVva6jKIVVo6IQDo=;
 b=FjacPcTHzj5cXOIt9bkmGCqbJyo2bZOXfLUdoRJJETQu13V2SOQ09vxLRnTU8P9/9M
 kJOmZHV5/ugZUhMYkPy3BH/dX8KA5KBAu70/ywlzuOuuoFsrIb3yr9bnd/GAHVTXw3GA
 HuWkwEfC8EFYSyeeUqqLQuprkGQAwhD5LVKMWiq4+c7KXnNbqfvzVzDmWJAxoCUqXKC1
 nybh8pJ4ABG0Fs4eUc24ggTpK7TTw7Mpo6Gv3nZQJnnfPY2JOHjEyyC7ZcfdA54kj2k0
 q9MMSDStK4M72PPJNeQUonFTN6ybtwsCnAWUig6E9p3ANXkVNb1JbhSJUH4QHi/p4C3C
 E+TQ==
X-Gm-Message-State: ALyK8tJdAYlKZ116znT3IW1imZktvwT28C6Q6yXm7AMTsjutSJA31OQ+VVFuge4hGWqtYXp5evBjOROzU2i7iQ==
X-Received: by 10.157.13.167 with SMTP id 36mr5357827ots.134.1465069972800;
 Sat, 04 Jun 2016 12:52:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.5.168 with HTTP; Sat, 4 Jun 2016 12:52:52 -0700 (PDT)
From: Noam Postavsky <npostavs@HIDDEN>
Date: Sat, 4 Jun 2016 15:52:52 -0400
X-Google-Sender-Auth: 9hsJmJALpPcLgi_14saWM_0nYz0
Message-ID: <CAM-tV-_Uig1vhm3ZJOjHJGxE7N2_r3Rie_D85RPN_0q5okC51A@HIDDEN>
Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -0.5 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.5 (/)

tag 22737 + notabug
quit3




Message received at control <at> debbugs.gnu.org:


Received: (at control) by debbugs.gnu.org; 21 Apr 2017 03:40:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Apr 20 23:40:24 2017
Received: from localhost ([127.0.0.1]:59590 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1d1PQl-0006v0-VY
	for submit <at> debbugs.gnu.org; Thu, 20 Apr 2017 23:40:24 -0400
Received: from mail-io0-f169.google.com ([209.85.223.169]:34631)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <npostavs@HIDDEN>) id 1d1PQk-0006ul-7o
 for control <at> debbugs.gnu.org; Thu, 20 Apr 2017 23:40:22 -0400
Received: by mail-io0-f169.google.com with SMTP id a103so101529425ioj.1
 for <control <at> debbugs.gnu.org>; Thu, 20 Apr 2017 20:40:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=sender:from:to:subject:date:message-id:mime-version;
 bh=PtzHQwosohXr0zcsw5zpHD4nLTPSPkOVPSIlQc2CUes=;
 b=dDJZOdzocoyOQOxDyuW692BgXz389HescY9GiyDsWT+SIDrGSR1ByXtvBBFC8/LFTk
 WI/NNhEoQpcQ+XGW32DZ0IfHZMXqu0FaMqALHplTVL/1xQtksHOKwaRP+wJ1A3J6NVM8
 cw5UHwiEStGeLfTGqij3aF11PCv+26SCn4BiKw0Zpvj5BPn+AdPYQCcg9AodsG63qpfn
 LrQ8ur+HIZFJvkIK7a1xlK5clfXlDJzMRc1BQn99dY9Uhmj+sD+jbh0cW9N+K02X8fvK
 uNNZewenV5kVaPFWqh0euQU2gx9Z5+CNlwyoYclxgHlR7bOMOJY3J6COIUopMZWpU/mx
 mOlQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:sender:from:to:subject:date:message-id
 :mime-version;
 bh=PtzHQwosohXr0zcsw5zpHD4nLTPSPkOVPSIlQc2CUes=;
 b=Qt5fnGvVhNRnWaecuzgd0PwT8MaaekfBwHWyzHJMfrYAVGt9A1ba3fHhfLAlQ4IE05
 6IJXbcEZlMihliHVQmcjEE/RoD/NFQqTSWX8q7NFGtLyksu1F1B769wmnf5F+6YKeGoZ
 zQvF518lcMwl/3tZnrjLQMoNF07e81QRppRSyHZGKxYobSX0TvZ2PYk7tMUFyxdkPxEK
 4KAJrQMcrldm22q0T52mR5qkPxkwQLcNRR/UwdZyfBDpkWAJ6dTapruLKHjeXxnNLwb+
 R5gArPXxxMHFo6+Y7VljGtQn8MtNxBuo0eiGBV+IDJ9X3ujMCI4+p+YN3U6BY0lqFMhI
 YJ6w==
X-Gm-Message-State: AN3rC/6JkYc1Khe4pXpfr6lsCI+FwDCf14QXDJX6dgQCieaLVGXLXKsI
 J4kHwkrGOfFQU/bh
X-Received: by 10.36.238.196 with SMTP id b187mr2035953iti.26.1492746015838;
 Thu, 20 Apr 2017 20:40:15 -0700 (PDT)
Received: from zony ([45.2.7.65])
 by smtp.googlemail.com with ESMTPSA id v89sm3603919iov.49.2017.04.20.20.40.15
 for <control <at> debbugs.gnu.org>
 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
 Thu, 20 Apr 2017 20:40:15 -0700 (PDT)
From: npostavs@HIDDEN
To: control <at> debbugs.gnu.org
Subject: control message for bug #22737
Date: Thu, 20 Apr 2017 23:41:45 -0400
Message-ID: <87d1c6qveu.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.1 (--)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.1 (--)

tags 22737 wontfix
quit






Last modified: Fri, 21 Apr 2017 03:45:01 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.