[TUHS] reviving a bit of WWB

[scj at yaccman.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 at 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.