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 16749 invoked from network); 5 Jun 2020 20:57:57 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 5 Jun 2020 20:57:57 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 6BBE89CA31; Sat, 6 Jun 2020 06:57:51 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 5532B93D56; Sat, 6 Jun 2020 06:57:18 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 1DA1693D56; Sat, 6 Jun 2020 06:57:15 +1000 (AEST) Received: from viclamta28p.bpe.bigpond.com (viclamta28p.bpe.bigpond.com [203.38.21.92]) by minnie.tuhs.org (Postfix) with ESMTPS id D524E93D52 for ; Sat, 6 Jun 2020 06:57:13 +1000 (AEST) Received: from smtp.telstra.com ([10.10.26.4]) by viclafep28p-svc.bpe.nexus.telstra.com.au with ESMTP id <20200605205711.UCTK7960.viclafep28p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com> for ; Sat, 6 Jun 2020 06:57:11 +1000 X-RG-Spam: Unknown X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgudegudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvffttedpqfgfvfenuceurghilhhouhhtmecugedttdenucenucfjughrpeffhffvufgjkfhffgggtgesthdttddttdervdenucfhrhhomhepffgrvhgvucfjohhrshhfrghllhcuoegurghvvgeshhhorhhsfhgrlhhlrdhorhhgqeenucggtffrrghtthgvrhhnpeekieetjeeuuefhfeeguedvudeifeevudfgvedtffekhfffjeekhfdutdetheethfenucfkphepuddutddrudeguddrudelfedrvdeffeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegrnhgvuhhrihhnrdhhohhrshhfrghllhdrohhrghdpihhnvghtpeduuddtrddugedurdduleefrddvfeefpdhmrghilhhfrhhomhepoegurghvvgeshhhorhhsfhgrlhhlrdhorhhgqedprhgtphhtthhopeeothhuhhhssehtuhhhshdrohhrgheq X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RG-VS-CLASS: clean Received: from aneurin.horsfall.org (110.141.193.233) by smtp.telstra.com (5.8.420) id 5E8A6D750AFC690C for tuhs@tuhs.org; Sat, 6 Jun 2020 06:57:11 +1000 Received: from aneurin.horsfall.org (localhost [127.0.0.1]) by aneurin.horsfall.org (8.15.2/8.15.2) with ESMTP id 055Kv9uY067508 for ; Sat, 6 Jun 2020 06:57:09 +1000 (EST) (envelope-from dave@horsfall.org) Received: from localhost (dave@localhost) by aneurin.horsfall.org (8.15.2/8.15.2/Submit) with ESMTP id 055Kv7dC067505 for ; Sat, 6 Jun 2020 06:57:09 +1000 (EST) (envelope-from dave@horsfall.org) X-Authentication-Warning: aneurin.horsfall.org: dave owned process doing -bs Date: Sat, 6 Jun 2020 06:57:06 +1000 (EST) From: Dave Horsfall To: The Unix Heritage Society mailing list In-Reply-To: Message-ID: References: <8a2e9b1b-8890-a783-5b53-c8480c070f2e@telegraphics.com.au> <95e6e8de901c837a28b84e62556ba326@firemail.de> User-Agent: Alpine 2.21.9999 (BSF 287 2018-06-16) X-GPG-Public-Key: http://www.horsfall.org/gpgkey.pub X-GPG-Fingerprint: 05B4 FFBC 0218 B438 66E0 587B EF46 7357 EF5E F58B X-Home-Page: http://www.horsfall.org/ X-Witty-Saying: "chmod 666 the_mode_of_the_beast" MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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" On Wed, 27 May 2020, Greg A. Woods wrote: > Sadly most compilers, including GCC and Clang/LLVM will, at best, warn > (and warnings are only treated as errors by the most macho|wise); and > compilers only do that now because they've been getting flack from > developers whenever the optimizer does something unexpected. Don't talk to me about optimisers... That's not the code that I wrote! I've seen code simply disappear, because the "optimiser" though that it was cleverer than I was. > The Linux kernel example I've referred to involved dereferencing a > pointer to do an assignment in a local variable definition, then a few > lines later testing if the pointer was NULL before using the local > variable. Unoptimised the code will dereference a NULL pointer and load > junk from location zero into the variable (because it's kernel code), > then the NULL test will trigger and all will be good. The optimizer > rips out the NULL check because "obviously" the programmer has assumed > the pointer is always a valid non-NULL pointer since they've explicitly > dereferenced it before checking it and they wouldn't want to waste even > a single jump-on-zero instruction checking it again. (It's also quite > possible the code was written "correctly" at first, then someone mushed > all the variable initialisations up onto their definitions.) Typical Penguin/OS behaviour... > In any case there's now a GCC option: -fno-delete-null-pointer-checks > (to go along with -fno-strict-aliasing and -fno-strict-overflow, and > -fno-strict-enums, all of which MUST be used, and sometimes > -fno-strict-volatile-bitfields too, on all legacy code that you don't > want to break) I'm sure that there's a competition somewhere, to see who can come with GCC's -fmost-longest-and-most-obscure-option flags... > It's even worse when you have to write bare-metal code that must > explictly dereference a NULL pointer (a not-so-real example: you want > to use location zero in the CPU zero-page (e.g. on a 6502 or 6800, or > PDP-8, etc.) as a pointer) -- it is now impossible to do that in strict > Standard C even though trivially it "should just work" despite the silly > rules. As far as I can tell it always did just work in "plain old" C. I've programmed a PDP-8! 'Twas way back in high school, and I found a bug in my mentor's program; it controlled traffic lights... > The crazy thing about modern optimizers is that they're way more > persistent and often somewhat more clever than your average programmer. > They follow all the paths. They apply all the rules at every turn. Optimisers... Grrr... -- Dave