From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 11:59:27 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20181210180033.GC4188@ACM> <20181211113420.GB4911@ACM> <20181211192001.GC4911@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1544558307 24574 195.159.176.226 (11 Dec 2018 19:58:27 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 19:58:27 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 20:58:23 2018 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 1gWoAg-0006Ht-Hb for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 20:58:22 +0100 Original-Received: from localhost ([::1]:41245 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWoCl-0000cr-TT for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 15:00:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52919) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWoBs-00007W-OW for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:59:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWoBo-00048l-N1 for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:59:36 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57946) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gWoBo-000473-79 for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:59:32 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id DECE11608EE; Tue, 11 Dec 2018 11:59:28 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mMAxVm6JOghH; Tue, 11 Dec 2018 11:59:28 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 047381608ED; Tue, 11 Dec 2018 11:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vv4OT7yqxazg; Tue, 11 Dec 2018 11:59:27 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id DC2341608C9; Tue, 11 Dec 2018 11:59:27 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <20181211192001.GC4911@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:231761 Archived-At: On 12/11/18 11:20 AM, Alan Mackenzie wrote: >> If so, aren't we limiting builds to platforms that have binutils, >> which would be a new restriction? > Well, we use ld, which also belongs to binutils, and that doesn't seem > to restrict the platforms. Other platforms surely have equivalents to > both objdump and ld, and they are/would be used appropriately. We don't use ld, at least not directly. The makefile uses $(CC), just as it uses $(CC) to compile. On GNU/Linux hosts this eventually uses ld (or gold or whatever), but those details are largely immaterial. If we required objdump or similar utilities, that would be yet another porting hassle. And we might run into platforms where there is no objdump-like utility and we have to write one ourselves. This doesn't sound good at all. > globals.h seems to manage. globals.h manages because we decorate every symbol it needs to find. If we have to decorate every C function that might call EQ (either directly or indirectly), that would also work but it would be a lot more intrusive than globals.h is. And the proposal to use objdump seems to acknowledge this, by proposing a method that wouldn't require such decoration but would have significant portability problems. > >> It should be easy enough to move shared file-static data into another >> file, that would be compiled only once. > Possibly not. The same would have to be done with file global data, > too. But doing it that way would involve a great deal of change to the > source code (testing for the -D option) which would not be popular. It'd be less change than having to decorate every function that might call EQ. > It would likely slow down the compilation by a very great deal. That's OK, if the cost is borne only by people who want accurate diagnostics. People who want compilation speed can simply turn off the accurate-diagnostics flag. > You're conflating "tedious" with "tedious in the extreme". We're estimating how much work would be needed. Even if there would be more work in changing the byte compiler, it shouldn't be so much more work that we need to contort all the rest of Emacs. It's better to localize such changes when possible. > This would place onerous restrictions on what macros were allowed to do, > and likely be incompatible with a vast proportion of existing macros. But under both proposals I mentioned, existing macros would work just fine with no new restrictions. So what I think you're saying is that if people want to write macros that allow for more-accurate diagnostics, they'll find that they can't easily do it for some reason. What reason would that be? Can you give an example based on some macro already defined in Emacs?