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 12:53:20 -0600 Message-ID: References: <87a8mxsn2g.fsf@oracle.com> <83lh6hrqm4.fsf@gnu.org> <83fuwiixnm.fsf@gnu.org> <83vb5bco99.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113319da150574052cb0d053 X-Trace: ger.gmane.org 1456512866 31516 80.91.229.3 (26 Feb 2016 18:54:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Feb 2016 18:54:26 +0000 (UTC) Cc: 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 19:54:17 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 1aZNWp-0004sj-AI for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 19:54:15 +0100 Original-Received: from localhost ([::1]:51676 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZNWo-0005iK-Jr for geb-bug-gnu-emacs@m.gmane.org; Fri, 26 Feb 2016 13:54:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZNWi-0005e9-0i for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 13:54:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZNWc-00033i-Ub for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 13:54:07 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50764) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZNWc-00033J-Qh for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 13:54:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aZNWc-00035F-GC for bug-gnu-emacs@gnu.org; Fri, 26 Feb 2016 13:54:02 -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 18:54: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.145651280811787 (code B ref 22737); Fri, 26 Feb 2016 18:54:02 +0000 Original-Received: (at 22737) by debbugs.gnu.org; 26 Feb 2016 18:53:28 +0000 Original-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 Original-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 Original-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== X-Received: by 10.50.183.2 with SMTP id ei2mr4133688igc.57.1456512800455; Fri, 26 Feb 2016 10:53:20 -0800 (PST) Original-Received: by 10.64.223.105 with HTTP; Fri, 26 Feb 2016 10:53:20 -0800 (PST) In-Reply-To: <83vb5bco99.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:113908 Archived-At: --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--