7 Oct
2020
7 Oct
'20
7:43 a.m.
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(a)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.