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: When should ralloc.c be used? (WAS: bug#24358) Date: Tue, 25 Oct 2016 19:05:16 +0300 Message-ID: <83pomowh1f.fsf@gnu.org> References: <87twe6sx2g.fsf@users.sourceforge.net> <87eg51ng4r.fsf_-_@users.sourceforge.net> <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <83d1iq5ib1.fsf@gnu.org> <83r3753c8j.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477412132 12968 195.159.176.226 (25 Oct 2016 16:15:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 16:15:32 +0000 (UTC) Cc: npostavs@users.sourceforge.net, eggert@cs.ucla.edu, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 18:15:27 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 1bz4Nm-0001aR-A8 for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 18:15:22 +0200 Original-Received: from localhost ([::1]:56221 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4Nj-0003DZ-3S for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 12:15:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33729) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4ET-0003EO-1V for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:05:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz4EO-0006rH-DV for emacs-devel@gnu.org; Tue, 25 Oct 2016 12:05:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45212) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz4ED-0006pT-Gz; Tue, 25 Oct 2016 12:05:29 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1375 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bz4E5-0000dv-HO; Tue, 25 Oct 2016 12:05:22 -0400 In-reply-to: (message from Richard Stallman on Mon, 24 Oct 2016 22:35:55 -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:208777 Archived-At: > From: Richard Stallman > CC: eggert@cs.ucla.edu, emacs-devel@gnu.org, > npostavs@users.sourceforge.net > Date: Mon, 24 Oct 2016 22:35:55 -0400 > > > > I think the way to fix those is by systematically looking at the > > > source for them, rather than by debugging. > > > Yes, but finding out whether this is so is not easy, because the > > malloc call is sometimes buried very deep. > > There are programs that determine call trees. We could find these > problems by analyzing the output. Yes, but the real problem is to determine whether the code needs any changes at all. For that, one must understand the control flow, and figure out whether pointers to buffer text are used across malloc calls without any updates. This is the hardest part, because pointers are frequently passed down to subroutines and to their subroutines, which use them or call malloc only under certain conditions. For example, it could be that a subroutine only calls malloc if the passed-in pointer does not originate from a buffer object. This analysis is what makes the source study hard. Anyway, I think I just finished hunting and fixing those cases, so the only remaining issue is with regex.c functions, for which we have a patch that will most probably do the job.