Comments on the preceeding bugs in System V

[Guy Harris]

> We are running SVR2 on a Vax 11/780 and have been for quite some time.
> We have noticed none of the problems you mentioned, and I even tried
> to duplicate a couple of them using your examples with no success --
> everything worked fine.  Now, are you *absolutely* sure that it wasn't
> your port to the 68000 that caused these problems?  Can anyone else
> on the net with an un-ported SVR2 duplicate any/all of these problems.

In no way does the fact that a particular example can be made to work on a
VAX prove that the bugs are due to the port, except in the sense that if
they'd ported to the VAX instead of the 68000 the bugs wouldn't have shown
up.  There are a LOT of bugs in S5R2V1 (note that he was reporting bugs in
V2) which don't show up on a VAX but definitely show up on machines where
there is no location 0 in a process' address space.

Programs which have bugs which cause them to dereference null pointers are
less likely to fail on VAX 4BSD or VAX System V because those system start
the text at location 0, so if you illegally use a null pointer as if it
pointed to something the machine can at least fetch data using that pointer.
(VAX/VMS, however, does it right; the first page of the address space is not
mapped.)  However, many other systems do not have a location 0 in the user's
address space, and any attempt to dereference a null pointer will get caught
immediately.

Changes have been posted to 4BSD to optionally have programs which, when
loaded into processes, have no location 0; System V Release 2 Version 2
already has this option - the "-z" flag to "ld".  I strongly suggest that
all future System V releases be built entirely with this option, so that
null pointer problems will get caught *before* the source gets shipped to
people with machines where this is not an option.  (I'd also suggest that
"-z" be made the default, but this would probably upset people by forcing
them to fix their code.)

My present company, and the company I worked at before then, both have
machines where processes do not have a location 0 which is accessible in
user mode; it is a real pain fixing all the "perfectly good" C code out
there to work on these machines.  The fact that it happens to work on VAXes
doesn't make it correct.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy at sun.arpa	(yes, really)