From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Conservative GC isn't safe Date: Sat, 26 Nov 2016 11:29:06 -0500 Message-ID: References: <66485157-00cd-4704-a421-cbfe84299cae@cs.ucla.edu> <83poli1di3.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480177768 19251 195.159.176.226 (26 Nov 2016 16:29:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Nov 2016 16:29:28 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 26 17:29:25 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 1cAfqs-0004QF-MZ for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 17:29:22 +0100 Original-Received: from localhost ([::1]:51022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAfqw-0001Iz-Az for ged-emacs-devel@m.gmane.org; Sat, 26 Nov 2016 11:29:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cAfqn-0001HH-WD for emacs-devel@gnu.org; Sat, 26 Nov 2016 11:29:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cAfqk-000867-TW for emacs-devel@gnu.org; Sat, 26 Nov 2016 11:29:18 -0500 Original-Received: from [195.159.176.226] (port=58267 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cAfqk-00084H-MV for emacs-devel@gnu.org; Sat, 26 Nov 2016 11:29:14 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cAfqe-0002Cn-O1 for emacs-devel@gnu.org; Sat, 26 Nov 2016 17:29:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 20 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:v9p+4bMDv8Nl0xuZE00Ok9vvV5g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:209620 Archived-At: > 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. > 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). I also think it could prove fiddly to avoid false positives. Stefan