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: [Emacs-diffs] emacs-25 ee04aed: Fix handling of buffer relocation in regex.c functions Date: Tue, 25 Oct 2016 19:22:36 +0300 Message-ID: <83insgwg8j.fsf@gnu.org> References: <20161023191028.10942.12099@vcs.savannah.gnu.org> <20161023191028.C103F220124@vcs.savannah.gnu.org> <83mvhu5kn0.fsf@gnu.org> <8360oh4tnt.fsf@gnu.org> <83oa2934yl.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477412824 18293 195.159.176.226 (25 Oct 2016 16:27:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 16:27:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 18:27:00 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 1bz4Yx-0003s9-Qk for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 18:26:55 +0200 Original-Received: from localhost ([::1]:56384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4Z0-0003VI-2R for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 12:26:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44745) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4VF-0001EY-Ss for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:23:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz4VC-0006CE-P0 for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:23:05 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46001) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4VC-0006C3-LQ; Tue, 25 Oct 2016 12:23:02 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1388 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bz4VA-0002ta-12; Tue, 25 Oct 2016 12:23:02 -0400 In-reply-to: (message from Stefan Monnier on Tue, 25 Oct 2016 08:20:25 -0400) 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:208782 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Tue, 25 Oct 2016 08:20:25 -0400 > > > The same is true for many other parts of Emacs: bidi.c, syntax.c, > > composite.c, to name just a few. > > I think it's worse because the answer to the question depends on > potentially the whole code (e.g. changing a piece of code such that it > now uses malloc means you have to check every caller (and caller's > caller, ...), and in other direction, when manipulating buffer text you > need to check every function you call (and the functions they call, ...) > to see if they may call malloc). True. But OTOH, the number of places where we call BYTE_POS_ADDR and then manipulate the result as a 'char *' is quite small. > > Sure. But we're already in the minefield, might as well be careful > > enough to not step on any mine, until we can get out. > > I think we can get out right away. No, not yet. First, we need to make sure that removing ralloc.c from the build works well and doesn't cause memory fragmentation or other unwanted side effects, and we need to do that both on GNU/Linux and on other supported platforms we care about, like *BSD. If some of these experience problems, we need to solve them, preferably without using ralloc.c. Only when there are no more platforms that use ralloc.c can we remove all those workarounds from the code. I agree that there's a good chance we'll achieve this goal soon enough, but we are not there yet. We just made the first step today in that direction. I'm not even sure we will be able to achieve this goal before Emacs 25.2 is released.