Newsgroups: comp.unix.wizards
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: null pointer problems and AT&T (was: att & osf)
Message-ID: <1988Sep13.212407.2749@utzoo.uucp>
Organization: U of Toronto Zoology
References: <4964@killer.DALLAS.TX.US> <3395@vpk4.UUCP> <1988Aug19.204836.23395@utzoo.uucp> <3165@homxc.UUCP> <1988Aug26.194505.25724@utzoo.uucp> <8391@smoke.ARPA>  <1477@oakhill.UUCP>
Date: Tue, 13 Sep 88 21:24:07 GMT

A friend of mine has asked me to post this for him:

====================================================

(A) SVVS when it was initially released had no NULL pointer problems.
     At that time it ran on everything from an XT to the Cray.

(B) Then initial development group was broken up and the work
     passed to another group inside of AT&T almost 2 years ago.
     Apparently they are not as careful as we were when we developed it.
     Pity...

But I wander away from the important issue, ie what should you do...

(C) The policy back then when you found SVVS errors was this.

    (Warning.....things may be different today, But I doubt it.

    (1) Are you really sure it's a bug with SVVS. If so...

    (2) Prepare your bug report with supporting evidence and what you
        think the correct interpretation might be. 

	We at the time considered it inexcusable to have a bug in SVVS. 
	If there was a legitemate bug in SVVS we fixed it. Bugs in SVVS
	meant that we as developers did not fully understand
	the nuances or the many interpretations that some
	routines had. But there is no shame in this.
	Not everyone can understand everything. We really
	did appreciate people finding bugs!

	NOTE: AT&T never claimed that SVVS, SVID, or anything else
	they produced is PERFECT. We KNEW that there were bugs.
	Some of the potentially EMBERASSING. We knew that only
	time would find them but the product was released when
	it was concidered acceptable for use. We KNEW it would
	evolve over time.

     (3) Call AT&T support and report the bug. Usually they would
        forward the bug to SVVS development. I don't know what
	happens these days.

     (4) A fair portion of bugs and be traced not to SVVS but to
	SVID and AT&T documentation and source. If the AT&T code doesn't
	match the documentation then call support and scream.
	Another problem with the SVID is that it is NOT detailed
	enough in defining and describing the "environment" for many
	particular system calls/library functions. This is
	unfortunate. I challenge you to call AT&T have have them
	clarify any ambiguities. If they won't listed then
	try and change it in a POSIX document. It's never too
	late to try if it's really important.

     (5) Yes, AT&T has delayed releases of System V in order for it
	to pass SVVS. Expecting AT&T to decertify a release is just
	silly. They will fix it over time.

     (6) AT&T will issue waivers for reasonable problems brought up
	 with either the SVID or SVVS. The waver process is negotiable
	 but you are on the weekest side. Be careful and reasonable
	 and expect to bend on certain issues. Read your SVVS license
	 carefully, it should explain the waver process. If not
	 call AT&T licensing in Greensborough.

Personal comment: Things at AT&T rarely improve unless they are given an
outside push. The scope of the SVID and SVVS is too large.
AT&T did not think through the problem of adding more extensions.
This has caused everyone a lot of grief. If you complain lound and
long enough AT&T will listen. The recent disaster with OSF is evidence
of this. Enough of this poor grammer and spelling, it's time
to get on with life.

	tom glinos
	former svvs hack
	utzoo!wildcan!tg

-- 
NASA is into artificial        |     Henry Spencer at U of Toronto Zoology
stupidity.  - Jerry Pournelle  | uunet!attcan!utzoo!henry henry@zoo.toronto.edu