From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 18 16:57:17 2016 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 ) id 1aWWZZ-0006aZ-Dw for submit@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 ) id 1aWWTX-0006R6-DN for submit@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 ) id 1aWWTR-0005yv-C8 for submit@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 ) id 1aWWTR-0005ym-96 for submit@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 ) id 1aWWTQ-0005tn-CS for bug-gnu-emacs@gnu.org; Thu, 18 Feb 2016 16:50:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aWWTL-0005to-CL for bug-gnu-emacs@gnu.org; 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 ) id 1aWWTL-0005te-4i for bug-gnu-emacs@gnu.org; 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 ; 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 ; 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 ; 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 To: bug-gnu-emacs@gnu.org Subject: 25.1; Finalizer should be optional in dynamic modules 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@oracle.com> 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-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 18 Feb 2016 16:57:16 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 19 04:34:10 2016 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 ) id 1aWhRy-0001Ed-I2 for submit@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 ) id 1aWhRw-0001EP-Rq for 22737@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 ) id 1aWhRo-00009U-IH for 22737@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jess Balint In-reply-to: <87a8mxsn2g.fsf@oracle.com> (message from Jess Balint on Thu, 18 Feb 2016 15:52:55 -0600) Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules References: <87a8mxsn2g.fsf@oracle.com> 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-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > From: Jess Balint > 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. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 17:47:20 2016 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 ) id 1aYLjk-0004Ic-3T for submit@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 ) id 1aYLjh-0004IO-Tp for 22737@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@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@gnu.org> References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> Date: Tue, 23 Feb 2016 16:47:12 -0600 Message-ID: Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules From: Jess Balint To: Eli Zaretskii Content-Type: multipart/alternative; boundary=94eb2c06b69cec431c052c77ba3e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 wrote: > > From: Jess Balint > > 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
If the data is unspecified it doesn'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't care to have Emacs doing= anything for me.

Thx.

Jess

On Fri, Feb 19, 2016= at 3:33 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Jess Balint <jbalint@gmail.com>
> Date: Thu, 18 Feb 2016 15:52:55 -0600
>
> Dynamic modules are really cool so far, but I think finalizers should<= br> > not be mandatory for user pointers (alloc.c):
>
> #ifdef HAVE_MODULES
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0else if (mblk->marke= rs[i].m.u_any.type =3D=3D Lisp_Misc_User_Ptr)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0{
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0struct Li= sp_User_Ptr *uptr =3D &mblk->markers[i].m.u_user_ptr;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uptr->= finalizer (uptr->p); <----- should NULL-check first
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
> #endif
>
> c.f. https://github.com/emac= s-mirror/emacs/blob/master/src/alloc.c#L6893

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
needs to be free'd when the user-pointer object is GC'ed; failure t= o
do so will cause memory leaks.=C2=A0 When is the above incorrect, or gets in your way?

Thanks.

--94eb2c06b69cec431c052c77ba3e-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 23 22:40:30 2016 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 ) id 1aYQJS-00087Z-Bk for submit@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 ) id 1aYQJR-00087N-Nz for 22737@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 ) id 1aYQJH-0004gV-MN for 22737@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jess Balint In-reply-to: (message from Jess Balint on Tue, 23 Feb 2016 16:47:12 -0600) Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> 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-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Tue, 23 Feb 2016 16:47:12 -0600 > From: Jess Balint > Cc: 22737@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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 11:17:33 2016 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 ) id 1aZL5B-0007kc-Jm for submit@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 ) id 1aZL5A-0007kP-30 for 22737@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@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@gnu.org> References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> Date: Fri, 26 Feb 2016 10:17:26 -0600 Message-ID: Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules From: Jess Balint To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c39aa6884fdd052caea2f1 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 wrote: > > Date: Tue, 23 Feb 2016 16:47:12 -0600 > > From: Jess Balint > > Cc: 22737@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
Situation #1 - globals:

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.

Situation #2 - manual memory management:

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'm required to supply a no-op finalizer= when creating these user pointers.

Thanks.
<= div>
Jess


On Tue, Feb 23, 2016 at 9:40 PM, Eli Zaret= skii <eliz@gnu.org> wrote:
>= Date: Tue, 23 Feb 2016 16:47:12 -0600
> From: Jess Balint <jbalint@gma= il.com>
> Cc: 22737@debbugs.gnu.org=
>
> If the data is unspecified it doesn't *necessarily* need to be fre= ed. 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 som= e cases I will be managing memory a bit
> more manually and don't care to have Emacs doing anything for me.<= br>
I don't think I follow.=C2=A0 How can you manage memory manually= when Emacs
does GC whenever it feels like it?=C2=A0 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-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 13:37:02 2016 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 ) id 1aZNGA-0002h8-8M for submit@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 ) id 1aZNG9-0002ge-3B for 22737@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 ) id 1aZNFz-0002j1-Au for 22737@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jess Balint In-reply-to: (message from Jess Balint on Fri, 26 Feb 2016 10:17:26 -0600) Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> 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-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > Date: Fri, 26 Feb 2016 10:17:26 -0600 > From: Jess Balint > Cc: 22737@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? From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 13:53:28 2016 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 ) id 1aZNW3-000343-OE for submit@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 ) id 1aZNW2-00033n-7r for 22737@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@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@gnu.org> References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> Date: Fri, 26 Feb 2016 12:53:20 -0600 Message-ID: Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules From: Jess Balint To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113319da150574052cb0d053 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113319da150574052cb0d053 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 12:36 PM, Eli Zaretskii wrote: > > Date: Fri, 26 Feb 2016 10:17:26 -0600 > > From: Jess Balint > > Cc: 22737@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
On F= ri, Feb 26, 2016 at 12:36 PM, Eli Zaretskii <eliz@gnu.org> wrot= e:
> Date: Fri, 26 Feb 2016 10:17:26 -= 0600
> From: Jess Balint <jbalint@gmail.com>
> Cc: 22737@debbugs.gnu.org=
>
> Situation #1 - globals:
>
> I have pointers to data that are global (not on the heap). I return th= ese pointers from module functions so that
> they may be used as parameters to other module function calls. These p= ointers should *never* be freed. In
> this case I need to supply a no-op finalizer when creating the user po= inter.
>
> 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 free= d only when explicitly requested. I may
> return many user pointers to the same heap-allocated structure. Even w= hen 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.?=C2=A0 Won't this cause all kind= s 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 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's been= freed, it'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 "magically modifying others".

Jess
--001a113319da150574052cb0d053-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 16:33:40 2016 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 ) id 1aZQ16-0008Pe-NW for submit@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 ) id 1aZQ15-0008PS-4i for 22737@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 ) id 1aZQ0z-0004mh-18 for 22737@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 ) 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 ) 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@gnu.org> From: Eli Zaretskii To: Jess Balint , Daniel Colascione , John Wiegley In-reply-to: (message from Jess Balint on Fri, 26 Feb 2016 12:53:20 -0600) Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> 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-Debbugs-Envelope-To: 22737 Cc: 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.0 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 16:51:50 2016 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 ) id 1aZQIg-0000Ns-BL for submit@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 ) id 1aZQIf-0000Nf-75 for 22737@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@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@gnu.org> References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> <83twkvcg30.fsf@gnu.org> Date: Fri, 26 Feb 2016 15:51:43 -0600 Message-ID: Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules From: Jess Balint To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a113ec85a088ac9052cb34eb7 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22737 Cc: Daniel Colascione , 22737@debbugs.gnu.org, John Wiegley X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113ec85a088ac9052cb34eb7 Content-Type: text/plain; charset=UTF-8 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. Thanks. Jess --001a113ec85a088ac9052cb34eb7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 26, 2016 at 3:33 PM, Eli Zaretskii <eliz@gnu.org> wrote:<= br>
> Date: Fri, 26 Feb 2016 12:53:20 -060= 0
> From: Jess Balint <jbalint@gmail.com>
> Cc: 22737@debbugs.gnu.org=
>
>=C2=A0 What will happen if such objects are exp= osed to Lisp, copied or
>=C2=A0 assigned to other Lisp variables, etc.? Won't this cause all= kinds of
>=C2=A0 trouble, like modifying one such object will magically modify se= veral
>=C2=A0 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 underlyin= g data are visible by all who have a
> pointer to the data. I wouldn't call this "magically modifyin= g others".

In C, yes.=C2=A0 But we are talking about Lisp objects here.

Am I the only one who is uneasy with supporting such Lisp objects?=C2=A0 If=
so, I will shut up and install the changes.=C2=A0 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 finalize= r will be called. It'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.

Thanks.
=

Jess
<= /div> --001a113ec85a088ac9052cb34eb7-- From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 26 16:55:11 2016 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 ) id 1aZQLv-0000TO-4s for submit@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 ) id 1aZQLt-0000TG-BX for 22737@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 ) id 1aZQLr-0001xu-9i; Fri, 26 Feb 2016 13:55:07 -0800 Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules To: Jess Balint , Eli Zaretskii References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> <83twkvcg30.fsf@gnu.org> From: Daniel Colascione Message-ID: <56D0C9B4.8070105@dancol.org> 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: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qVOuXh82dX4cCBfMKswnNjXIqENlmlh79" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 22737 Cc: John Wiegley , 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 > wrote: >=20 > > 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 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-- From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 29 15:28:21 2016 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 ) id 1aaUQW-0005mC-UY for submit@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 ) id 1aaUQV-0005m0-P0 for 22737@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@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@dancol.org> 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> Date: Mon, 29 Feb 2016 14:28:14 -0600 Message-ID: Subject: Re: bug#22737: 25.1; Finalizer should be optional in dynamic modules From: Jess Balint To: Daniel Colascione Content-Type: multipart/alternative; boundary=089e013a084cfb3fb0052cee7ce6 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22737 Cc: Eli Zaretskii , John Wiegley , 22737@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --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-- From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 04 15:53:00 2016 Received: (at control) by debbugs.gnu.org; 4 Jun 2016 19:53:00 +0000 Received: from localhost ([127.0.0.1]:54635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b9Hcy-0001mK-2G for submit@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 ) id 1b9Hcw-0001m8-Ks for control@debbugs.gnu.org; Sat, 04 Jun 2016 15:52:58 -0400 Received: by mail-oi0-f51.google.com with SMTP id w184so174272445oiw.2 for ; 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 Date: Sat, 4 Jun 2016 15:52:52 -0400 X-Google-Sender-Auth: 9hsJmJALpPcLgi_14saWM_0nYz0 Message-ID: Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules To: control@debbugs.gnu.org Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -0.5 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) tag 22737 + notabug quit3 From debbugs-submit-bounces@debbugs.gnu.org Thu Apr 20 23:40:24 2017 Received: (at control) by debbugs.gnu.org; 21 Apr 2017 03:40:24 +0000 Received: from localhost ([127.0.0.1]:59590 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d1PQl-0006v0-VY for submit@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 ) id 1d1PQk-0006ul-7o for control@debbugs.gnu.org; Thu, 20 Apr 2017 23:40:22 -0400 Received: by mail-io0-f169.google.com with SMTP id a103so101529425ioj.1 for ; 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 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 20 Apr 2017 20:40:15 -0700 (PDT) From: npostavs@users.sourceforge.net To: control@debbugs.gnu.org Subject: control message for bug #22737 Date: Thu, 20 Apr 2017 23:41:45 -0400 Message-ID: <87d1c6qveu.fsf@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.1 (--) tags 22737 wontfix quit From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 15 07:33:55 2019 Received: (at control) by debbugs.gnu.org; 15 Jul 2019 11:33:56 +0000 Received: from localhost ([127.0.0.1]:46707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmzEx-00089f-Og for submit@debbugs.gnu.org; Mon, 15 Jul 2019 07:33:55 -0400 Received: from quimby.gnus.org ([80.91.231.51]:41042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hmzEv-00089W-Cd for control@debbugs.gnu.org; Mon, 15 Jul 2019 07:33:53 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=marnie) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hmzEs-0006M9-Lh for control@debbugs.gnu.org; Mon, 15 Jul 2019 13:33:52 +0200 Date: Mon, 15 Jul 2019 13:33:50 +0200 Message-Id: <87blxvcz1d.fsf@mouse.gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #22737 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 22737 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 22737 quit From unknown Mon Jun 23 22:05:31 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 13 Aug 2019 11:24:06 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator