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=DKIM_SIGNED,DKIM_VALID, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8325 invoked from network); 27 May 2020 14:38:39 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 14:38:39 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id BB0BE9C873; Thu, 28 May 2020 00:38:34 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6A7519C5F1; Thu, 28 May 2020 00:38:01 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; secure) header.d=mxes.net header.i=@mxes.net header.b="PR4aXynu"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id E5D7C9C5F1; Thu, 28 May 2020 00:37:58 +1000 (AEST) Received: from smtp-out-3.mxes.net (smtp-out-3.mxes.net [198.205.123.68]) by minnie.tuhs.org (Postfix) with ESMTPS id 30DA59C5EC for ; Thu, 28 May 2020 00:37:58 +1000 (AEST) Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 16328759B2 for ; Wed, 27 May 2020 10:37:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mxes.net; s=mta; t=1590590276; bh=slpebDWGBKCfjnsfKLM2YO/tVVThKaopjjn40pGW9K8=; h=From:Content-Type:Mime-Version:Subject:Date:References:To: In-Reply-To:Message-Id; b=PR4aXynu8gIJ10Bp9BXZTVpui2xCgS9KsRngPIJ6+TGSWxcVbV0mpK7KuUo9ItwxH 3hq8Iwds4947InNVa8KhZwZJyQ26yLcisGsD28sATYT6ZG3Q34utN2Qf5gS+VNxM7A sxMGD3CW1Dpqp0cLX2yQHFJnl9QXaGt7ArYmJdco= From: Ronald Natalie Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Wed, 27 May 2020 10:37:53 -0400 References: <8a2e9b1b-8890-a783-5b53-c8480c070f2e@telegraphics.com.au> To: The Unix Heritage Society mailing list In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Sent-To: 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" The large areas of undefined and unspecified behavior has always been an = issue in C. It was somewhat acceptable when you were using it as a = direct replacement for assembler, but Java and many of other follow-ons endevaored to be more = portable/rigourous. Of course, you can write crap code in any = language. It didn=E2=80=99t take modern C to do this. On the PDP-11 (at least = not in split I/D mode), location zero for example contained a few = assembler instructions (p&P6) which you could print out. Split I/D and VAX implementations made this even worse by putting a 0 at = location 0. When we moved from the VAX to other processors we had = location zero unmapped. For the first time, accessing a null pointer ended up trapping rather than = either resulting in a null (or some random data). Eventually, we = added a feature to the kernel called =E2=80=9CBraindamanged Vax compatibility Mode=E2=80=9D that restored the zero to location zero. = This was enabled by a field we could poke into the a.out header = because this was needed on things we didn=E2=80=99t have source code to (things we did we just fixed). Similar nonsense we found where the order that function args are = evaluated was relied upon. The PDP-11, etc=E2=80=A6 evaluated them = right-to-left because that=E2=80=99s how they had to push them on the stack for the call linkage. We had one machine that did that in = the opposite order (I considered flipping the compiler behavior anyhow0 = and when we got to the RISC architectures, things were passed in registered so the evaluation was less predictable. I already detailed the unportability problem I found where the BSD = kernel =E2=80=9Cconverted by union=E2=80=9D. The most amusing thing I=E2=80=99d have to say was that one day I got a = knock on my office door. One of the sales guys from our sister company = wanted to know if I could write some Novell drivers for an encrypting ethernet card they were selling. The = documentation for writing the driver was quite detailed but all = describing i386 assembler interfaces (and the examples were in assembler). About a week into the project I came to = realization that the linkages were all the C subroutine calls for that = platform. The caller was C and there was no particular reason why the driver wasn=E2=80=99t also written in C.