From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jess Balint Newsgroups: gmane.emacs.bugs Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules Date: Fri, 26 Feb 2016 15:51:43 -0600 Message-ID: References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> <83twkvcg30.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113ec85a088ac9052cb34eb7 X-Trace: ger.gmane.org 1456523542 11207 80.91.229.3 (26 Feb 2016 21:52:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 21:52:22 +0000 (UTC) Cc: John Wiegley , 22737@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 22:52:13 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZQJ1-0007fy-V9 for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 22:52:12 +0100 Original-Received: from localhost ([::1]:52249 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQJ1-0004Dc-Bf for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 16:52:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57341) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQIx-0004DD-4L for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:52:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZQIs-0007XO-7A for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:52:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQIs-0007WT-0C for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:52:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZQIr-0000OQ-Jz for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:52:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jess Balint Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Feb 2016 21:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22737 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22737-submit@debbugs.gnu.org id=B22737.14565235101484 (code B ref 22737); Fri, 26 Feb 2016 21:52:01 +0000 Original-Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 21:51:50 +0000 Original-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 Original-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 Original-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== X-Received: by 10.107.135.212 with SMTP id r81mr9708376ioi.59.1456523503493; Fri, 26 Feb 2016 13:51:43 -0800 (PST) Original-Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 13:51:43 -0800 (PST) In-Reply-To: <83twkvcg30.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:113913 Archived-At: --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--