From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#22737: 25.1; Finalizer should be optional in dynamic modules Date: Fri, 26 Feb 2016 13:55:00 -0800 Message-ID: <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qVOuXh82dX4cCBfMKswnNjXIqENlmlh79" X-Trace: ger.gmane.org 1456523783 15130 80.91.229.3 (26 Feb 2016 21:56:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 21:56:23 +0000 (UTC) Cc: John Wiegley , 22737@debbugs.gnu.org To: Jess Balint , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 26 22:56:11 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aZQMs-0001bO-Vf for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 22:56:11 +0100 Original-Received: from localhost ([::1]:52272 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQMs-0005NT-IG for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 16:56:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59668) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQMp-0005NL-C0 for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:56:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZQMk-0001Dp-SP for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:56:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50812) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZQMk-0001Dk-Oh for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:56:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZQMk-0000Ua-JK for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 16:56:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 26 Feb 2016 21:56:02 +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.14565237111827 (code B ref 22737); Fri, 26 Feb 2016 21:56:02 +0000 Original-Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 21:55:11 +0000 Original-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 Original-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==; Original-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 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: 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:113915 Archived-At: 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--