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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10014 invoked from network); 21 Sep 2020 21:23:02 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 21 Sep 2020 21:23:02 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 16F729CBCA; Tue, 22 Sep 2020 07:22:59 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id B6A8D940FD; Tue, 22 Sep 2020 07:22:24 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="qvfz/0uM"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9F60D93D5F; Tue, 22 Sep 2020 07:22:21 +1000 (AEST) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by minnie.tuhs.org (Postfix) with ESMTPS id 10E3793D33 for ; Tue, 22 Sep 2020 07:22:21 +1000 (AEST) Received: by mail-vs1-f53.google.com with SMTP id a16so8993288vsp.12 for ; Mon, 21 Sep 2020 14:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5Z3wmZbaCl3IpkvrZ/MSVXU2eOQDeI/dY4WVKvB8VTk=; b=qvfz/0uMNi5B5t4LJqfGJMUcuQwcrLw94vZ8/pvbbfSncnF5GhxmcEovycW8VCxT4J z2XtgXvj6Rk+IlMR3atKviSz7YAuCJcb4A8KdWMv//F9SivYd2zN/BmQomm00FcwUTQ+ ahIufdBCnGGNV2FkNwCnN4wCiq6Fh0f2L3V5yWxPQb3AfGgcVicpAJPAg4DqtHF8roms kQf0Hzn9X4NpfEvDzjSF4hqfN2g8PKRkBOhpay4XRXur6i6KD7Gv8mXf35J9TWRa1QU6 /qGR2pzhdRCTG7b8Y3dq2qw+8YBwLjA7joCbJKzT41Tb84oyEjAkLciGF0iXexhqmUW0 KALQ== 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=5Z3wmZbaCl3IpkvrZ/MSVXU2eOQDeI/dY4WVKvB8VTk=; b=RivWi3Y3XSt/Ivz19ZEQ1lCYUET+pbCCNxYfWii0mMnikaq48gsUA9//UlGlxVBo1V IbXg+aexOW4Z8s/FpIYsCQ1NrXXYdw8B1w8EWnh8Jb7r6E2yYzMIdG+qN9ztrEjL99eM cz9StKJHUrW1pNpvzZF8eQGht6zkoKetWNRiku/j5ZkR6ARgBNbezFFaY3XQ019B3tBh nh0hNrcfW6sk7b/4KrzB0Sq+uzspf3xHgYpDO9rUnku48e1qMW8XI+mne56kCF1EPB9M uFXV0vRbvAiYmVKFEGo/kXq/kLq6ovmImOnCjsxWoW6wiugxfnfcgVTyLc2lNLS9mo5L s40g== X-Gm-Message-State: AOAM533UkR1rJjbILAk+ZCpqz9PE6ndEqO8xIa4OiUMTNdrTBt5ZCROt 9vdlDZV3+tUFY2/q1WlI7QO6lagum95OzCDoN7l/KHwEAkk= X-Google-Smtp-Source: ABdhPJzk7Yvl4CGnw8Dcw5aIdUtrEqJv0lxiUE/UfNmmSjG5R/SQSwxMxgSQu0TXSmy0zNfp+UYaSN/rOjy/sVgJADM= X-Received: by 2002:a67:6bc6:: with SMTP id g189mr1583572vsc.18.1600723339963; Mon, 21 Sep 2020 14:22:19 -0700 (PDT) MIME-Version: 1.0 References: <20200920230057.C5D1A4422E@lignose.oclsc.org> In-Reply-To: From: Rob Pike Date: Tue, 22 Sep 2020 07:22:08 +1000 Message-ID: To: John Cowan Content-Type: multipart/alternative; boundary="0000000000000ff15505afd972c3" Subject: Re: [TUHS] reviving a bit of WWB 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 Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" --0000000000000ff15505afd972c3 Content-Type: text/plain; charset="UTF-8" Back when we were running v5 at the University of Toronto, we had a graphics device that we accessed, on our split I&D space 11/45, using 0, something like this: struct x { int reg0, reg1, ...; }; 0->reg1 = 0234; Several old details of old C made this possible as well: Struct tags were global, -> worked on any pointer, and ints and pointers were interchangeable. -rob On Tue, Sep 22, 2020 at 6:51 AM John Cowan wrote: > > > On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas wrote: > > >> I've never written anything that uses varargs, so I've never run into >> that. But I've actually done quite a bit of work with an environment >> where this isn't true: MS-DOS using the large or huge model. In this >> environment, sizeof(int)=2, and sizeof(void*) is 4. Of course, it's not >> conformant to pass an int variable as an argument where a pointer variable >> is expected. >> > > If the compiler was ISO-conformant (which it almost certainly was not), > that would not matter. 0 in int context would be a 2-byte int with all > bits zero, and 0 in pointer context would be a 4-byte null pointer, > probably with all bits zero. > > C doesn't require that the address represented by the null pointer > (whether or not it is all-bits-zero) is inaccessible, merely that there is > no C object or function there. A simple shim of the appropriate size (1, > 2, 4, 8 bytes depending on the CPU's alignment rules) will suffice. > > --0000000000000ff15505afd972c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Back when we were running v5 at the University of Toronto,= we had a graphics device that we accessed, on our split I&D space 11/4= 5, using 0, something like this:

struct x {
= =C2=A0 =C2=A0int reg0, reg1, ...;
};

0-&= gt;reg1 =3D 0234;

Several old details of old C mad= e this possible as well: Struct tags were global, -> worked on any point= er, and ints and pointers were interchangeable.

-r= ob


On Tue, Sep 22, 2020 at 6:51 AM John Cowan <cowan@ccil.org> wrote:


On Mon, Sep 21, 2020 at 1:55 AM Steve Nickolas <usotsuki@buric.co> wrote:
=C2=A0
I= 9;ve never written anything that uses varargs, so I've never run into <= br> that.=C2=A0 But I've actually done quite a bit of work with an environm= ent
where this isn't true: MS-DOS using the large or huge model.=C2=A0 In t= his
environment, sizeof(int)=3D2, and sizeof(void*) is 4. Of course, it's n= ot conformant to pass an int variable as an argument where a pointer variab= le is expected.

If the compiler was ISO= -conformant (which it almost certainly was not), that would not matter.=C2= =A0 0 in int context would be a 2-byte int with all bits zero, and 0 in poi= nter context would be a 4-byte null pointer, probably with all bits zero.

C doesn't require that the address represented = by the null pointer (whether or not it is all-bits-zero) is inaccessible, m= erely that there is no C object or function there.=C2=A0 A simple shim of t= he appropriate size (1, 2, 4, 8 bytes depending on the CPU's alignment = rules) will suffice.

--0000000000000ff15505afd972c3--