Dereferencing NULL (includes a bug in S5 "tabs" command)

[Guy Harris]

> I've been informed by e-mail that there may be such a loader option (-z).
> ... (I still think it should be the default.)

YES!  ABSOLUTELY!  At the very least, ALL utilities for System V should be
built with this flag, and the system NOT considered to pass QA unless these
utilities do NOT drop core as a result of dereferencing a null pointer.

(4.2BSD has fewer of these problems, but that's only because it has to run
on a Sun which gives you no choice about getting errors on dereferencing
null pointers.  John Bruner posted some kernel and loader changes to give
4.2BSD a "-Z" option which functions like the S5 "-z" option - it makes an
executable image which, when run, causes location 0 not to be mapped into
the address space of the process.  VAX/VMS, of course, does this by
default.)

> Incidentally, *NULL bugs are especially elusive on a vax, since address
> zero normally contains (short)0 (the entry mask for start).

Which fact caused some turkeys to write code for 4.1BSD which DEPENDED on
this; it used NULL as the name of a null string!  Needless to say, by the
time this got running on a Sun, it was fixed....

> Bonus question: Why does tabs.c call   strcmp(set_tab,"f(")   ?

Because "f(" happens to be at location 0 on the machine that the implementor
was developing it on, and said implementor was too stupid to realize that
the CORRECT test was "set_tab == NULL", and not 'strcmp(set_tab, "f(") == 0)'?

Sometimes I think that every C language course should include a section on
"The Use and Abuse of Null Pointers"... unfortunately, I have yet to see
this mentioned in any such course's syllabus.

> Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint

Given the quality of too many C programs (and programmers), that title
sounds like a thankless task at best....
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa	(yes, really)