The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: scj@yaccman.com
To: Brantley Coile <brantley@coraid.com>
Cc: tuhs@tuhs.org, Doug McIlroy <doug@cs.dartmouth.edu>
Subject: Re: [TUHS] reviving a bit of WWB
Date: Tue, 06 Oct 2020 22:43:31 -0700	[thread overview]
Message-ID: <45073554951079046be7f0058933b050@yaccman.com> (raw)
In-Reply-To: <7F7B78DB-A3B5-4137-9301-E356A5C7EB88@coraid.com>

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 <usotsuki@buric.co> 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 <stddef.h>,
>>> 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.

  reply	other threads:[~2020-10-07  5:50 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-19  1:51 Doug McIlroy
2020-09-20 18:42 ` arnold
2020-09-20 19:28   ` Will Senn
2020-09-20 20:12     ` Steve Nickolas
2020-09-20 20:26       ` Doug McIlroy
2020-09-20 20:57         ` Doug McIlroy
2020-09-20 22:13           ` Clem Cole
2020-09-21 20:43             ` Steffen Nurpmeso
2020-09-20 20:58         ` Steve Nickolas
2020-09-20 21:33           ` Brantley Coile
2020-10-07  5:43             ` scj [this message]
2020-09-20 21:35           ` John Cowan
2021-02-02 23:08             ` Greg A. Woods
2021-02-02 23:47               ` Larry McVoy
2021-02-03  0:11                 ` Dave Horsfall
2021-02-03  0:19                   ` Larry McVoy
2021-02-03  2:04                     ` Richard Salz
2021-02-03  3:32                       ` Dave Horsfall
2021-02-03  4:32                         ` M Douglas McIlroy
2021-02-03 11:27                           ` Peter Jeremy via TUHS
2021-02-03 20:09                             ` Dave Horsfall
2021-02-03 20:13                               ` Niklas Karlsson
2021-02-03 23:46                               ` Tom Lyon
2021-02-03 22:19                           ` Dave Horsfall
2021-02-03 22:55                             ` M Douglas McIlroy
2020-09-20 22:15           ` Clem Cole
2020-09-20 22:47             ` John Cowan
2020-09-21 20:48               ` Steffen Nurpmeso
2020-09-21 20:46           ` Steffen Nurpmeso
2020-09-24  2:25       ` Dave Horsfall
2020-09-24  2:33         ` Clem Cole
2020-09-25  0:18           ` [TUHS] One's complement (was: reviving a bit of WWB) Greg 'groggy' Lehey
2020-09-25  0:22             ` Warner Losh
2020-09-25  1:39               ` John Cowan
2020-09-27  5:54           ` [TUHS] reviving a bit of WWB Dave Horsfall
2020-09-24 17:19         ` Paul Winalski
2020-09-24 18:17           ` John Cowan
2020-10-07  5:47   ` scj
2020-10-07  9:20     ` arnold
2020-10-08  0:27     ` Dave Horsfall
2020-10-08  3:08       ` John Cowan
2020-09-20 22:51 Norman Wilson
2020-09-20 23:00 Norman Wilson
2020-09-20 23:53 ` Clem Cole
2020-09-21  0:00   ` Clem Cole
2020-09-21  2:24     ` John Cowan
2020-09-21  0:09   ` Warner Losh
2020-09-21  1:05     ` Clem Cole
2020-09-21  5:55     ` Steve Nickolas
2020-09-21  5:59       ` Warner Losh
2020-09-21 18:40         ` Paul Winalski
2020-09-21 19:56           ` Dan Cross
2020-09-21 20:50       ` John Cowan
2020-09-21 21:22         ` Rob Pike
2020-09-21 21:57           ` Clem Cole
2020-09-21 23:56             ` John Cowan
2020-09-22  0:54               ` Richard Salz
2020-09-21 21:39         ` Steve Nickolas
2020-09-25 14:19 Doug McIlroy
2020-09-28 17:35 ` Angelo Papenhoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45073554951079046be7f0058933b050@yaccman.com \
    --to=scj@yaccman.com \
    --cc=brantley@coraid.com \
    --cc=doug@cs.dartmouth.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).