From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Development Speed Date: Thu, 23 Dec 2021 14:12:44 -0500 Message-ID: References: <83r1a4yfpt.fsf@gnu.org> <8335mky4rl.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32372"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, eliz@gnu.org To: xenodasein@tutanota.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Dec 23 20:14:46 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n0TY4-0008AC-Rx for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Dec 2021 20:14:45 +0100 Original-Received: from localhost ([::1]:59926 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0TY2-0006G6-WB for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Dec 2021 14:14:43 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39322) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0TWZ-0005GM-Se for emacs-devel@gnu.org; Thu, 23 Dec 2021 14:13:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48349) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0TWN-0006gG-DT; Thu, 23 Dec 2021 14:13:10 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 058BA805CE; Thu, 23 Dec 2021 14:12:57 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C905C805AC; Thu, 23 Dec 2021 14:12:51 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1640286771; bh=Sh1nF+qEikR8Y0IjeNQie9MVHVeIg1nQIy3xxCUVb0o=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=iOndqw2qVxL1B5KsUn65fMCp8wpTGSXmYqdFSbZl0FdKxt91qLl2gpIMRH/VOGsto 4djyehx1uIduxo2H9aErBY9hZuFcFQbtkodmhOeop2PD0AjgvafS8/Rh4MNDo+601n DUzkOEI8F0mZT15jLi/tzQHQvhDbdQWCL79QY2PU5zKqr2EkqS5QJ+IMihGYLaxieh fiZSASOfKbf9+9uG7Pk9+t4a7LPqCVbphUwPPxC+IxVXhcT0Tm/rd72myWGGfuKcRo 3B2x4Oiau2AhvYHcCo9orMjblltRTCGi3EFrBvWA0p7ukimXWhbNXS+MfAYQBnp02n giQPPRCoKpXMg== Original-Received: from ceviche (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 9B0D9120185; Thu, 23 Dec 2021 14:12:51 -0500 (EST) In-Reply-To: (xenodasein@tutanota.de's message of "Thu, 23 Dec 2021 18:35:50 +0100 (CET)") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:283011 Archived-At: > In the same vein, my thought at least, it was more about making the code > more standard compliant, predictable, rather than specific features. I'd be surprised if the compliance (or not) of Emacs's C code with specific versions of the C standard would make any difference to a newcomer. The difficulty in our C code comes from various aspects, none of which have much to do with the C language itself: - The use of macros to wrap accesses/definitions of Lisp data/functions. REmacs had a slightly better story there, but still with the same "this is not your vanilla Rust code" problem. - The actual logic of the code. - The cruft accumulated over the years. - The impact of the (conservative) GC which implies that things aren't always what they appear to be (e.g. when our string compaction moves string data under the feet of unsuspecting C code). Over the years, we've managed to reduce the use of macros (replaced by inlinable functions) to some extent, partly thanks to improvement in compilers, but it didn't change much to the code overall. > I can't see how this is something to ask over small patches, as > in a patch that says "Make these few lines of code C17 compliant" > wouldn't mean much without a plan. If you describe a concrete problem linked to being "not C17 compliant", then maybe we can start thinking about a plan. But so far all I've seen is "compliance for its own sake". I don't even know of any single place where we're not "C17 compliant". Stefan