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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11856 invoked from network); 27 May 2020 15:10:47 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 27 May 2020 15:10:47 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 77E7F9C919; Thu, 28 May 2020 01:10:45 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 474C19C5EC; Thu, 28 May 2020 01:10:15 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="cwo/I2fU"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id CAF589C5EC; Thu, 28 May 2020 01:10:11 +1000 (AEST) Received: from mail-qk1-f180.google.com (mail-qk1-f180.google.com [209.85.222.180]) by minnie.tuhs.org (Postfix) with ESMTPS id 04CF29C5E9 for ; Thu, 28 May 2020 01:10:11 +1000 (AEST) Received: by mail-qk1-f180.google.com with SMTP id b27so14632222qka.4 for ; Wed, 27 May 2020 08:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Q22rBY2m4RM30eM5d4duaM5g/ietv3L/vLIS9DWVXVY=; b=cwo/I2fU3VBFQ7qnqkAhgoLPHwUGjy+MMMbdUwj3Xggt0p1veLyEGBKu22lgARe4f6 0hxsaZnaKGyg5S05GY5baCZci1FNQx7LlQZfbCbtpbjTyzLOZo9WT9yO3CeK598G2PJZ DShngOCdzEWXt6y9io6MDSzho7wmAwyJ3aWOY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Q22rBY2m4RM30eM5d4duaM5g/ietv3L/vLIS9DWVXVY=; b=O6bsjBsAk1/Ori8DG2LagTNtxpFUnyeLlyNndI1nU92Rb537iRHzYa3B+fvO6Zi3yK LIl+P+vqu21S4KuhbzWFFdrNgqv7WyAKUf9XQ/wYu2wXJ11YYVLi4Q1r99XLBnjh4xDm ssSvJsiV26NtGq+VXblmQrIZg+PThEwp95jQv1fy6Nk7ZlGaBi8tkFOD/xq6uLCGCDns G+f29U5KYcHdeMStL7JER3VXXIfqWe43FV72QS0XMmnyWptiaWkiFVY1wodXerPnu2UY eMj+FGGDT3DmtwYt5AFqvtXNxt6LrSdzWSc3Gtq/W9CzVO/gMntUOQssN47q2QRyNi4r wzuA== X-Gm-Message-State: AOAM5331oN3IUO9jA44vngrKQzYEMzXpjbZsflXT5Oh/E4XLohfoZGcC oMRr8ICwGDQ8y1KxkSmooVBNY8jLZ1LNviTyMCSlyg== X-Google-Smtp-Source: ABdhPJzHEwGI4hrbNYxvx4OLFgtBNF2GA4ejpCnnTlYPVfKT/ptUeDG+gkU56Lvn0dOeG3FU23Pb/D8maixj76OKKW0= X-Received: by 2002:a05:620a:1321:: with SMTP id p1mr4538184qkj.476.1590592209877; Wed, 27 May 2020 08:10:09 -0700 (PDT) MIME-Version: 1.0 References: <8a2e9b1b-8890-a783-5b53-c8480c070f2e@telegraphics.com.au> In-Reply-To: From: Clem Cole Date: Wed, 27 May 2020 11:09:43 -0400 Message-ID: To: Ronald Natalie Content-Type: multipart/alternative; boundary="000000000000a71b3d05a6a29b35" 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: , Cc: The Unix Heritage Society mailing list Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --000000000000a71b3d05a6a29b35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Henry Spencer's 10 Commandments for C Programmers On Wed, May 27, 2020 at 10:38 AM Ronald Natalie wrote: > 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 dire= ct > 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 instructio= ns > (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 w= as > 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 evaluate= d > 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 a= nd > 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 k= nock 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 describin= g > 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. T= he > caller was C and there was no particular > reason why the driver wasn=E2=80=99t also written in C. > > --000000000000a71b3d05a6a29b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <= br>
On Wed,= May 27, 2020 at 10:38 AM Ronald Natalie <ron@ronnatalie.com> wrote:
The large areas of undefined and unspecified beha= vior has always been an issue in C.=C2=A0 =C2=A0It 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/rigour= ous.=C2=A0 =C2=A0Of course, you can write crap code in any language.

It didn=E2=80=99t take modern C to do this.=C2=A0 =C2=A0On the PDP-11 (at l= east not in split I/D mode), location zero for example contained a few asse= mbler instructions (p&P6) which you could print out.
Split I/D and VAX implementations made this even worse by putting a 0 at lo= cation 0.=C2=A0 =C2=A0 When we moved from the VAX to other processors we ha= d location zero unmapped.=C2=A0 =C2=A0For the
first time, accessing a null pointer ended up trapping rather than either r= esulting in a null (or some random data).=C2=A0 =C2=A0 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.=C2= =A0 =C2=A0This was enabled by a field we could poke into the a.out header b= ecause 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.=C2=A0 The PDP-11, etc=E2=80=A6=C2=A0 evaluated them right-= to-left because that=E2=80=99s how they had to push them
on the stack for the call linkage.=C2=A0 =C2=A0We had one machine that did = that in the opposite order (I considered flipping the compiler behavior any= how0 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 kno= ck on my office door.=C2=A0 =C2=A0One of the sales guys from our sister com= pany wanted to know if I could write some Novell
drivers for an encrypting ethernet card they were selling.=C2=A0 =C2=A0 The= documentation for writing the driver was quite detailed but all describing= i386 assembler interfaces (and the examples
were in assembler).=C2=A0 =C2=A0About a week into the project I came to rea= lization that the linkages were all the C subroutine calls for that platfor= m.=C2=A0 =C2=A0 The caller was C and there was no particular
reason why the driver wasn=E2=80=99t also written in C.

--000000000000a71b3d05a6a29b35--