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_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3642 invoked from network); 7 Oct 2020 05:50:25 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 7 Oct 2020 05:50:25 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id 03A0F9CF83; Wed, 7 Oct 2020 15:50:22 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 6D3599CF6D; Wed, 7 Oct 2020 15:49:46 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=yaccman.com header.i=@yaccman.com header.b="E2YmQI1t"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 9DED09CF6D; Wed, 7 Oct 2020 15:49:41 +1000 (AEST) X-Greylist: delayed 364 seconds by postgrey-1.36 at minnie.tuhs.org; Wed, 07 Oct 2020 15:49:40 AEST Received: from beige.elm.relay.mailchannels.net (beige.elm.relay.mailchannels.net [23.83.212.16]) by minnie.tuhs.org (Postfix) with ESMTPS id D6AB59CF59 for ; Wed, 7 Oct 2020 15:49:40 +1000 (AEST) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 0BC3921C81; Wed, 7 Oct 2020 05:43:33 +0000 (UTC) Received: from pdx1-sub0-mail-a14.g.dreamhost.com (100-96-9-93.trex.outbound.svc.cluster.local [100.96.9.93]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 62E8021CA8; Wed, 7 Oct 2020 05:43:32 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from pdx1-sub0-mail-a14.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.10); Wed, 07 Oct 2020 05:43:32 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|scj@yaccman.com X-MailChannels-Auth-Id: dreamhost X-Belong-Harmony: 4fcbc0994b826e06_1602049412727_2024047605 X-MC-Loop-Signature: 1602049412727:2896657554 X-MC-Ingress-Time: 1602049412726 Received: from pdx1-sub0-mail-a14.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTP id 1ABE67F333; Tue, 6 Oct 2020 22:43:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=yaccman.com; h= mime-version:date:from:to:cc:subject:in-reply-to:references :message-id:content-type:content-transfer-encoding; s= yaccman.com; bh=blBd4pZyFlovhkqlHERamw8VrfM=; b=E2YmQI1tlkzEXOnF Mde/xiAwiCHEokTraVtf7e3QjL6qk1ni80goSlDFYek1CFk04JjKI1y0CLw4oh7k Um2UUxda0kvNboqQi8iDWfuLa21FK1IVejuS2P2GH046Rwq2Sr3lx+9ZFia54Pfr eve7ZpEwTEGAk1jc6nvnObr7s9Y= Received: from webmail.dreamhost.com (ip-66-33-200-4.dreamhost.com [66.33.200.4]) (Authenticated sender: scj@yaccman.com) by pdx1-sub0-mail-a14.g.dreamhost.com (Postfix) with ESMTPA id A170F7F332; Tue, 6 Oct 2020 22:43:31 -0700 (PDT) MIME-Version: 1.0 Date: Tue, 06 Oct 2020 22:43:31 -0700 X-DH-BACKEND: pdx1-sub0-mail-a14 From: scj@yaccman.com To: Brantley Coile In-Reply-To: <7F7B78DB-A3B5-4137-9301-E356A5C7EB88@coraid.com> References: <202009190151.08J1pYnb066792@tahoe.cs.dartmouth.edu> <202009201842.08KIgn2f022401@freefriends.org> <04211470-AD63-452A-A0BB-6A7A6FD85AAE@gmail.com> <202009202026.08KKQ2x6137303@tahoe.cs.dartmouth.edu> <7F7B78DB-A3B5-4137-9301-E356A5C7EB88@coraid.com> User-Agent: DreamHost Webmail/1.4.1 Message-ID: <45073554951079046be7f0058933b050@yaccman.com> X-Sender: scj@yaccman.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit 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: tuhs@tuhs.org, Doug McIlroy Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" This discussion of null pointers reminds me of one of the hardest things we came upon porting what became V7 to the Interdata 4/32. Earlier UNIX systems had returned -1 as an error indicator from some system calls that returned a pointer. We made a strong effort to find these, but they were everywhere and we didn't get them all (another motivation for Lint...). We were finding crashes on the Interdata with the machine halted and none of the error registers (including the location of the fault) making any sense. After a couple of frustrating weeks, we found the problem. The Interdata was a microcoded machine. If it tried to access -1 as an address, it immediately got an "unaligned access" fault and dove into the microcode. Before it has saved its status registers, the memory system chimed in with another fault -- memory access out of bounds. The combination trashed everything. When we met with Interdata to explore whether they wanted to sell Unix on their hardware, fixing this was one of our non-negotiable demands. They said no. We walked. Several years later, of course, Unix did show up there, but they missed a great opportunity. --- On 2020-09-20 14:33, Brantley Coile wrote: > The fact that a pointer of zero generates a hardware trap is not > defined in the language, whereas a 0 is is defined to be a null > pointer. > > I've worked on systems where a 0 pointer could be dereferenced without > a trap. I wouldn't recommend it. System designers do things like make > the first page of memory invalid so we will get a null pointer trap. > On Plan 9 the beginning of the text segment starts at 0x1020. > > But that's not part of the C language. The fact that 0 is a null > pointer is. > > Brantley > >> On Sep 20, 2020, at 4:58 PM, Steve Nickolas wrote: >> >> On Sun, 20 Sep 2020, Doug McIlroy wrote: >> >>>> (Of course, that assumes NULL is 0, but I don't think I've run into >>>> any >>>> architecture so braindead as to not have NULL=0.) >>> >>> It has nothing to do with machine architecture. The C standard >>> says 0 coerces to the null pointer. NULL, defined in , >>> is part of the library, not the language. I always use 0, >>> because NULL is a frill. >>> >>> Doug >> >> I was under the impression that there was explicitly no requirement >> that a null pointer be 0, and that there was at least one weird system >> where that wasn't true - that it just so happened that null points to >> 0 on certain CPUs and that 0=NULL *happens* to work on most CPUs but >> wasn't guaranteed. (In fact, I read that my habit of using 0 for NULL >> relied on a faulty assumption!) >> >> I mean, I've never actually used a CPU/OS/compiler where it wasn't >> true, but... >> >> -uso.