From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7451 invoked from network); 14 Mar 2023 02:49:41 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 14 Mar 2023 02:49:41 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id EF8DD41610; Tue, 14 Mar 2023 12:49:34 +1000 (AEST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by minnie.tuhs.org (Postfix) with ESMTPS id 0618B4160D for ; Tue, 14 Mar 2023 12:49:29 +1000 (AEST) Received: from cwcc.thunk.org (pool-173-48-120-46.bstnma.fios.verizon.net [173.48.120.46]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 32E2nNI7022947 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 13 Mar 2023 22:49:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1678762165; bh=v9M74tOvPdRa/bCIIFBXSWf2300b/NMuow3bb5zaGxI=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=SWTFKdBRRqEw+1j+FgEc8h/bOwTmb/U4k4MSiJd7HLLTUJkGyBwl0a/twjiYMKeUJ ntesPoqRX/jxV/Q+s5CtAcEznR8cBdFwEDn86zPpdVqR0sV+IVGJUYmGl9HHwPO0sk xLlPKaPYDTQsqPv49cvebsmVupfUTJX2B+XpYmV9aOO0uHYqZsVkQYERa+T67o3FQ5 4+tguRYhSWgcHtRCKEl+A1QtzEW7uUCDLY+dj5OHOXJ+PGcmGNabKhn4CJfcFdHlTg K7zgSKno0cvDqWj5xUO2ax4nSMn5CZUtV95i4emg9CNPuQQKgolUQQI+k9XNy25pTj zSAlk3XDE+gPw== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 9936A15C5830; Mon, 13 Mar 2023 22:49:23 -0400 (EDT) Date: Mon, 13 Mar 2023 22:49:23 -0400 From: "Theodore Ts'o" To: Paul Winalski Message-ID: <20230314024923.GN860405@mit.edu> References: <20230310113708.AD55518C080@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Message-ID-Hash: 3QHH5NS3A2MD45YAAYPSA5VY57ZJL3PO X-Message-ID-Hash: 3QHH5NS3A2MD45YAAYPSA5VY57ZJL3PO X-MailFrom: tytso@mit.edu X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Alejandro Colomar , TUHS X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [TUHS]: C dialects (was: I can't drive 55: "GOTO considered harmful" 55th anniversary) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon, Mar 13, 2023 at 12:00:04PM -0400, Paul Winalski wrote: > > Note that the goal of a programming language standards committee is > very different from the goal of those who use the language. The > committee's goal is to standardize existing practice of the language > in a way that is implementable on the widest range of hardware and OS > platforms, and to provide a controlled way to add language extensions. It's worse than that. Programming language stanrds committees are dominated by engineers working on compilers, and there are very few (I personally know of only one) OS engineers who might be trying to *use* the language in a kernel where you have interrupt handlers, etc., and don't like the fact that the compiler might optimize the code in such a way that it moves instructions out from a critical region, etc. > The advantage of programming in strict ISO C is that the resulting > code will run just about anywhere. If you don't care about that (and > I'd wager most programmers don't) then ignore the standard. For a sufficiently important program, it's possible for the authors to say --- the C standard is just ***insane*** and if you want us to support compilation of say, the Linux kernel by your compiler, you *must* provide knobs to turn off certain insane "features" of the C language spec. GCC and Clang have those knobs, so you could say that it they support the Linux kernel "dialect". And the fact that this dialect isn't blessed by the ISO committee doesn't cause me to lose any sleep at night. > As someone pointed out, the three things that most programmers value > are execution speed, execution speed, and execution speed. Aliasing > issues greatly hamper what a modern optimizing compiler can do and > still generate semantically correct code. Compiler companies who are playing benchmark wars care about execution speed --- of benchmark programs. I'm not sure how many programmers actually care about some of these optimizations, because there aren't *that* many programs that are really CPU bound, and many which appear to be CPU bound are often hitting memory bandwidth / caching issues, which are not necessarily the things which tricky compiler optimizations can fix. As an OS engineer, I deeply despise these optimization tricks, since I personally I care about correctness and not corrupting user data far more than I care about execution speed ---- especially when the parts of the kernel I work on tend not to be CPU bound in the first place. - Ted