From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Sat, 26 Nov 2016 18:42:51 +0200 Message-ID: <83oa1219bo.fsf@gnu.org> References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <83poli1di3.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1480178622 20385 195.159.176.226 (26 Nov 2016 16:43:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 16:43:42 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 17:43:38 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cAg4f-0004nH-IU for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 17:43:37 +0100 Original-Received: from localhost ([::1]:51054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAg4j-0003fS-9q for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 11:43:41 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44024) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAg4c-0003fB-N2 for emacs-devel@gnu.org; Sat, 26 Nov 2016 11:43:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAg4X-0004Gi-RZ for emacs-devel@gnu.org; Sat, 26 Nov 2016 11:43:34 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42422) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAg4X-0004Ge-O2; Sat, 26 Nov 2016 11:43:29 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4222 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1cAg4U-0008Rk-TH; Sat, 26 Nov 2016 11:43:29 -0500 In-reply-to: (message from Stefan Monnier on Sat, 26 Nov 2016 11:29:06 -0500) 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-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:209621 Archived-At: > From: Stefan Monnier > Date: Sat, 26 Nov 2016 11:29:06 -0500 > > > Documentation aspects aside, if by "manipulate struct interval" you > > mean what we do in intervals.c between the call to make_interval and > > the return value being plugged into some Lisp object, either a buffer > > Yes, basically, that kind of manipulation. All of these cases are in intervals.c. There are no other calls to make_interval anywhere in our sources. So the question is: are those _the_only_ cases that you are talking about, or do you see any others? > > or a string, then we could set a variable during that time, which > > would cause an abort in GC, if that happens somehow. > > Such a var would only catch some of the possible issues I think > (there's also the issue of when we take an existing struct interval > pointer, remove it from one lvalue and plug it into another, plus > various other cases). > > IOW it sounds difficult to make such a test be "complete" (catch > most/all cases). That doesn't mean we shouldn't do what we can. Provided that we consider this danger to be real, of course. > I also think it could prove fiddly to avoid false positives. How can this cause false positives? The current code doesn't allow any GC in those functions I described above. This is purely a defensive technique against possible changes in the future which will mistakenly allow that.