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 12065 invoked from network); 27 May 2020 20:14:17 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 20:14:17 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 7F6F69C6BC; Thu, 28 May 2020 06:14:14 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 969E99C5E9; Thu, 28 May 2020 06:13:50 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id B81CB9C5E9; Thu, 28 May 2020 06:13:48 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 408D29C5E5 for ; Thu, 28 May 2020 06:13:48 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id CD2D535E0AE; Wed, 27 May 2020 13:13:47 -0700 (PDT) Date: Wed, 27 May 2020 13:13:47 -0700 From: Larry McVoy To: The Unix Heritage Society mailing list Message-ID: <20200527201347.GY22882@mcvoy.com> References: <95e6e8de901c837a28b84e62556ba326@firemail.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [TUHS] History of popularity of C X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" So I may have just gotten lucky in my 30+ years of writing C code but I have yet to hit a single instance of this doom and gloom. On Wed, May 27, 2020 at 12:49:25PM -0700, Greg A. Woods wrote: > 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 -- --- Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm