From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Towards a cleaner build Date: Fri, 17 May 2019 08:33:36 -0400 Message-ID: References: <831s0xd3z1.fsf@gnu.org> <83pnohbhny.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="492"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Lars Ingebrigtsen , Eli Zaretskii , Emacs developers To: Noam Postavsky Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri May 17 14:35:49 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hRc5V-0018Dd-Oj for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 14:35:49 +0200 Original-Received: from localhost ([127.0.0.1]:47994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRc5U-0000Zo-Mk for ged-emacs-devel@m.gmane.org; Fri, 17 May 2019 08:35:48 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:47558) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hRc3l-0007hN-0l for emacs-devel@gnu.org; Fri, 17 May 2019 08:34:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hRc3d-0007Ih-5g for emacs-devel@gnu.org; Fri, 17 May 2019 08:33:56 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26662) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hRc3R-00078T-RR; Fri, 17 May 2019 08:33:41 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0E8D610087A; Fri, 17 May 2019 08:33:41 -0400 (EDT) Original-Received: from mail02.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7BE741006F4; Fri, 17 May 2019 08:33:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1558096419; bh=0dNgEikK5KtLUVU8IC81KvOItXU5BfaU0Qk0OczukVE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=cEcXBb9JhzpRFTvlgjwTVApjVg5mTS2S3jrHlxgRkNrRi1x08rs5oKqGFaqdXv5LB 9u6MMtNqGmDTeWTFtSVxRsGHGoKh2Bg8k8rUc3+QSLBe2daXk/QDVJSHoadqvXeex2 0WGpJiod+wmb0DLM8KxwVY7Fsa9uMmqztmN6WkzQcu48KKHzZ4ijYrbXZ2sqjwr1sp iIHpUhBrmuLXJwM6+oWyOX5i6IoUY8NziSYfUk8uXDzziRj+aHNsnSAIXFNvGUgmmV goQaady3fsaRN8eG2VSBECBWY5sbm9WN8+0vEopVCBRgI0uWKcdnrHDxPYikJyxn24 B1T0yK3upLZvQ== Original-Received: from pastel (184-175-13-248.dsl.teksavvy.com [184.175.13.248]) by mail02.iro.umontreal.ca (Postfix) with ESMTPSA id E6727120AC4; Fri, 17 May 2019 08:33:38 -0400 (EDT) In-Reply-To: (Noam Postavsky's message of "Fri, 17 May 2019 07:25:01 -0400") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 132.204.25.50 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:236659 Archived-At: > This makes sense, but it should come for free. There's never any point > in issuing a warning about not using the advertised calling convention > from inside the function itself. Similarly, we shouldn't issue > warnings about calls to obsolete functions from bodies of functions > that are themselves obsolete. I generally agree, but there's a tension: this kind of reasoning can be pushed pretty far and the amount of coding involved can be hard to justify. So there's also something to be said for leaving the implementation dumb and asking the coder to add a few more with-(no|fewer|suppressed)-warnings. IOW whether it's worth the effort depends on the amount of complexity needed in the compiler and the number of false-positives it eliminates (and potentially the number of false-negatives it adds, tho this is rarely a problem). Stefan