🚀 go-pugleaf

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.
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd allegra ]!burl!rcj
			...![ ihnp4 cbosgd decvax watmath ]!clyde!rcj

In article <566@stride.stride.UUCP> bruce@stride.UUCP (Bruce Robertson) writes:
>Just a quick question... these are *serious* bugs in a *production* version
>of System V.  These aren't bugs due to our port to the 68000.  Also, these
>are NEW bugs; none of them existed in Release 1 of System V. I know that
>AT&T does Beta testing.  All of the bugs showed up within days of installing
>the new stdio package, and were tracked down and fixed within a couple of
>weeks.  I don't understand how they could have been missed by a
>thorough Beta test.  Does AT&T just ignore Beta test results, or is it
>just very careless when choosing Beta sites?

It would be interesting to hear how AT&T tests their code.
I have made literally over a thousand bug fixes to SVR2 (V1)
user-mode source code so far, and as you observe, many of
the bugs were newly introduced.  Interestingly, although I'm
one of the major redistributors of UNIX System V source code
to UNIX System vendors, I've never even been approached by
AT&T about being a code or SVID reviewer, test site, etc.

By the way, thanks for sharing your bug fixes.

AT&T turned us down to be a Beta site for Version 3, because they felt
that we "aren't committed to UNIX".  I don't see how they get that idea,
since UNIX is the primary operating system on our machines.
-- 

	Bruce Robertson
	UUCP: cbosgd!utah-cs!utah-gr!stride!bruce
	ARPA: stride!bruce@utah-gr.arpa

> 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@sun.arpa	(yes, really)