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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9326 invoked from network); 27 May 2020 19:50:01 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 19:50:01 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id E98169C90C; Thu, 28 May 2020 05:49:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id EDC819C5EC; Thu, 28 May 2020 05:49:31 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 6E96D9C5EC; Thu, 28 May 2020 05:49:28 +1000 (AEST) Received: from central.weird.com (unknown [198.96.117.51]) by minnie.tuhs.org (Postfix) with ESMTP id 632459C5E9 for ; Thu, 28 May 2020 05:49:27 +1000 (AEST) Received: from (invalid client hostname: bind: DNS error: DNS lookup for A for 'more.local': Unknown host)more.local ((no PTR matching greeting name)S01060026bb6c284e.ok.shawcable.net[24.71.254.93] port=35034) by central.weird.com([198.96.117.51] port=587) via TCP with esmtp (6056 bytes) (sender: ) (ident using UNIX) id for ; Wed, 27 May 2020 15:49:26 -0400 (EDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #78 built 2020-Mar-25) Received: from (invalid client hostname: the DNS A record (with the targegt address [10.0.1.129]) for the hostname 'more.local' does not match the expected address [10.0.1.129])more.local ((no PTR matching greeting name)future.local[10.0.1.133] port=65429) by more.local([10.0.1.129] port=25) via TCP with esmtp (5546 bytes) (sender: ) id for ; Wed, 27 May 2020 12:49:25 -0700 (PDT) (Smail-3.2.0.122-Pre 2005-Nov-17 #1 built 2015-Feb-17) Message-Id: Date: Wed, 27 May 2020 12:49:25 -0700 From: "Greg A. Woods" To: The Unix Heritage Society mailing list In-Reply-To: <95e6e8de901c837a28b84e62556ba326@firemail.de> References: <8a2e9b1b-8890-a783-5b53-c8480c070f2e@telegraphics.com.au> <95e6e8de901c837a28b84e62556ba326@firemail.de> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.3 (x86_64--netbsd) MULE/6.0 (HANACHIRUSATO) X-Face: ; j3Eth2XV8h1Yfu*uL{<:dQ$#E[DB0gemGZJ"J#4fH*][ lz; @-iwMv_u\6uIEKR0KY"=MzoQH#CrqBN`nG_5B@rrM8,f~Gr&h5a\= List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --pgp-sign-Multipart_Wed_May_27_12:49:12_2020-1 Content-Type: text/plain; charset=US-ASCII At Wed, 27 May 2020 18:11:33 +0200, "Thomas Paulsen" wrote: Subject: Re: [TUHS] History of popularity of C > > When I'm doing C I always have the CPU and its instructions in mind. And that's exactly what might trip you up unless you _exactly_ understand how the language standard defines the operations of the abstract virtual machine (right down to the implications of every sequence point in the code); how compilers and optimizers do and (more importantly) do not work when mapping the abstract virtual machine operations into real-world machine instructions; and what how _all_ instances of "undefined behaviour" can arise, and exactly what the optimizer is allowed to do when and if it spots UB conditions in the code. A big part of the problem is that the C Standard mandates compilation will and must succeed (and allows this success to be totally silent too) even if the code contains instances of undefined behaviour. This means that the successful execution of the generated code may depend on what optimization level was chosen. Code that does security tests on input values might be entirely and silently eliminated by the optimizer because of some innocuous-seeming UB instance, and this is exactly what has happened in the Linux kernel, for example (probably more than once). UB can be introduced quite innocently just by moving sequence points in variable references in ways that are not necessarily obvious even to seasoned programmers (and indeed "seasoned" programmers are often the ones who's old-fashioned coding habits might lead to introduction of serious problems in such a way). I've found dozens of instances of UB in mature and well tested code, and sometimes only by luck of having chosen the "right" compiler and enabled its feature of introducing illegal instructions in places where UB might occur, _and_ having had the luck to test in such a way as to encounter the specific code path where this UB occurred. I would claim it's truly safer now to write C without understanding the underlying mechanics of the CPU and memory, but rather by just paying very close attention to the detailed semantics of the language, understanding only the abstract virtual C machine, and hoping your compiler will at least warn if anything even remotely suspicious is done in your code; and lastly (but perhaps most importantly) avoiding like the plague any coding constructs which might make UB harder to spot (e.g. never ever initialize local variables with their definition when pointers are involved). Unfortunately the new "most advanced" C compilers also make it quite a bit more difficult for those of us writing C code that must have specific actions on the bare metal hardware, e.g. in embedded systems, kernels, hardware drivers, etc.; including especially where UB detection tools are far more difficult to use. -- Greg A. Woods Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms --pgp-sign-Multipart_Wed_May_27_12:49:12_2020-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP Digital Signature -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQTWEnAIIlcZX4oAawJie18UwlnHhQUCXs7EOwAKCRBie18UwlnH hbIOAKCqluN8iKaH3CUykyJBvUixZX+yTQCeJf3AhQ7wbg0A7oJrS3/0yl4dhqQ= =pVOn -----END PGP SIGNATURE----- --pgp-sign-Multipart_Wed_May_27_12:49:12_2020-1--