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 15:10:34 -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="22283"; 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 21:11:26 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 1n0UQw-0005ZP-BG for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Dec 2021 21:11:26 +0100 Original-Received: from localhost ([::1]:58998 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0UQu-0004Kk-Ta for ged-emacs-devel@m.gmane-mx.org; Thu, 23 Dec 2021 15:11:24 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:53532) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0UQE-0003a4-Cf for emacs-devel@gnu.org; Thu, 23 Dec 2021 15:10:42 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25145) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0UQB-0002od-Oa; Thu, 23 Dec 2021 15:10:41 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 33CC34428BF; Thu, 23 Dec 2021 15:10:37 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8E8AD4428BC; Thu, 23 Dec 2021 15:10:35 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1640290235; bh=Qmy2tM4b5Wn7jEME+B3sJb5zX2l44ppllM/TQFWpdFs=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=Ld0LR73zsCFecjpj5gfyaf6dACcCRoDmdCpTv7IompGjHpw9OYI33iorNTpJknVDA X8oUkPNyEBjBtDHpc/UoUS03NdGgaOP1vBNat81ke0igzCB8A8fV3BX8jwe6FPcp/f WVElQcAhaxEV4SyIJwy9xw/kxsUT59IJ1UAwyFxly//zsSpexqgYGBLoNGjGSDEDPm 3ploEJhNUTzU2WyJw/MG4wqE80pduFKz6NMz9tZJMY3QoHTCmQb/Zp0hFP8bGEQU7f axGHkEkzQlbLDt0Tj+j8vx5esQIL6ZN1e53PAf09nyfEokRKry6LkPWV5Pdu+/a+m6 o0yFqXRxcQj3w== Original-Received: from ceviche (unknown [216.154.30.173]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 42C7C1203C4; Thu, 23 Dec 2021 15:10:35 -0500 (EST) In-Reply-To: (xenodasein@tutanota.de's message of "Thu, 23 Dec 2021 20:53:10 +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:283031 Archived-At: >> If you describe a concrete problem linked to being "not C17 compliant", >> then maybe we can start thinking about a plan. > I had heard of studies showing how most bugs in important > C software were resulting from UBs, i.e. having wrong assumptions > on what you write; [ Never heard of such studies. ] It's definitely not the case that most of the bugs we fix in Emacs result from UB. There isn't much code in Emacs which suffers from UB, as far as I know. That code is quite crucial, OTOH (it's typically the bit-twiddling we use to manipulate the tagbits of `Lisp_Object` and the conservative stack scanning): I don't know how to write this without going outside of the specs of C (or Rust for that matter). > Hell, didn't they invent Rust just to avoid these issues? Not that I know, no. It had to do with avoiding memory management and concurrency bugs, as far as I know. And yes I have heard of studies that showed that memory safety and concurrency are the most common sources of bugs in C-style languages. >> But so far all I've seen is "compliance for its own sake". > Even when it made zero technical improvements, it would make soft > improvements especially for future. Given that I still don't know of any place in Emacs's C code where we're not compliant, I'm not sure that's the case. >> ... - The cruft accumulated over the years. ... > Language would help with this, I think. I don't think so. Such cruft is just the result of having to change code you don't know or understand enough to be sure exactly what to do, so you write your change so as to preserve as much of the previous behavior to be on the safe side. Language doesn't come into the picture very much. Test suites and "memory" (e.g. having the original author(s) around) do to some extent. >> I don't even know of any single place where we're not "C17 compliant". > I'm confused, does this mean it is possible to fully build Emacs > with "-std=c17"? I'd assume so until proven otherwise. Stefan