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 20294 invoked from network); 20 Sep 2020 21:48:55 -0000 Received: from minnie.tuhs.org (45.79.103.53) by inbox.vuxu.org with ESMTPUTF8; 20 Sep 2020 21:48:55 -0000 Received: by minnie.tuhs.org (Postfix, from userid 112) id CF3199CE4F; Mon, 21 Sep 2020 07:48:52 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 1512D940FD; Mon, 21 Sep 2020 07:48:17 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id B2D8A940FD; Mon, 21 Sep 2020 07:48:13 +1000 (AEST) X-Greylist: delayed 901 seconds by postgrey-1.36 at minnie.tuhs.org; Mon, 21 Sep 2020 07:48:12 AEST Received: from server907.appriver.com (server907a.appriver.com [204.232.250.39]) by minnie.tuhs.org (Postfix) with ESMTPS id 384A293F5B for ; Mon, 21 Sep 2020 07:48:12 +1000 (AEST) X-Note: This Email was scanned by AppRiver SecureTide X-Note-AR-ScanTimeLocal: 09/20/2020 5:32:55 PM X-Note: SecureTide Build: 8/26/2020 12:34:02 PM UTC (2.15.0.0) X-Note: Filtered by 10.246.0.223 X-Note-AR-Scan: None - PIPE Received: by server907.appriver.com (CommuniGate Pro PIPE 6.2.12) with PIPE id 20451091; Sun, 20 Sep 2020 17:32:55 -0400 Received: from [10.246.0.39] (HELO smtp.us.exg7.exghost.com) by server907.appriver.com (CommuniGate Pro SMTP 6.2.12) with ESMTPS id 20451089; Sun, 20 Sep 2020 17:32:52 -0400 Received: from E16DN31A-S1E7.exg7.exghost.local (192.168.244.15) by E16DN14B-S1E7.exg7.exghost.local (192.168.244.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2044.0; Sun, 20 Sep 2020 17:33:06 -0400 Received: from E16DN31A-S1E7.exg7.exghost.local ([192.168.244.15]) by E16DN31A-S1E7.exg7.exghost.local ([192.168.244.15]) with mapi id 15.01.2044.000; Sun, 20 Sep 2020 17:33:06 -0400 From: Brantley Coile To: Steve Nickolas Thread-Topic: [TUHS] reviving a bit of WWB Thread-Index: AQHWjieJYT3YkC9CnkSi00QoFT6NpKlyImyAgAAMpQCAAAxuAIAAA8QAgAAJK4CAAAmSAA== Date: Sun, 20 Sep 2020 21:33:06 +0000 Message-ID: <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> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [99.102.142.76] x-rerouted-by-exchange: MIME-Version: 1.0 Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable X-Note: This Email was scanned by AppRiver SecureTide X-Note-AR-ScanTimeLocal: 09/20/2020 5:32:52 PM X-Note: SecureTide Build: 8/26/2020 12:34:02 PM UTC (2.15.0.0) X-Note: Filtered by 10.246.0.223 X-Policy: GLOBAL X-Primary: GLOBAL@coraid.com X-Note-Sender: X-Virus-Scan: V- X-Note-SnifferID: 0 X-GBUdb-Analysis: 1, 192.168.244.15, Ugly c=0.735662 p=-0.990476 Source White X-Signature-Violations: 0-0-0-4793-c X-Note-419: 15.6253 ms. Fail:0 Chk:1375 of 1375 total X-Note: VSCH-CT/SI: 0-1375/SG:1 9/20/2020 5:32:09 PM X-Note: Spam Tests Failed: X-Country-Path: PRIVATE->PRIVATE-> X-Note-Sending-IP: 10.246.0.39 X-Note-Reverse-DNS: X-Note-Return-Path: brantley@coraid.com X-Note: User Rule Hits: X-Note: Global Rule Hits: G742 G743 G744 G745 G763 G764 G765 G1148 X-Note: Encrypt Rule Hits: X-Note: Mail Class: VALID 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" 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.=20 I've worked on systems where a 0 pointer could be dereferenced without a tr= ap. 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 b= eginning 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: >=20 > On Sun, 20 Sep 2020, Doug McIlroy wrote: >=20 >>> (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=3D0.) >>=20 >> 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. >>=20 >> Doug >=20 > 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 tha= t wasn't true - that it just so happened that null points to 0 on certain C= PUs and that 0=3DNULL *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 assu= mption!) >=20 > I mean, I've never actually used a CPU/OS/compiler where it wasn't true, = but... >=20 > -uso.