Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!husc6!cs.utexas.edu!oakhill!ed
From: ed@oakhill.UUCP (Ed Rupp)
Newsgroups: comp.unix.wizards
Subject: Re: null pointer problems and AT&T (was: att & osf)
Message-ID: <1477@oakhill.UUCP>
Date: 31 Aug 88 06:35:36 GMT
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>
Reply-To: ed@oakhill.UUCP (Ed Rupp)
Organization: Motorola Inc., Austin Tx.
Lines: 37

gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>henry@utzoo.uucp (Henry Spencer) writes:
>>a little bird tells me that *THE SVVS ITSELF* has NULL-pointer problems!!!
>
>???  What could this possibly mean?  I don't recall seeing any SOURCE CODE
>in the SVID!  And how could an INTERFACE SPEC have a "null pointer problem"?

SVID is not a program, SVVS is.

We have definitely found NULL pointer bugs in SVVS,  I can
furnish details on request.  Also, there seems
to be an unintended dependency on the default stty modes in the terminal
tests.   Other grossness:  there is a function called zprintf (or something
like that) that has 26 (count em!) integer args that it eventually
passes to printf.  This is okay on a 32100 chip because the stack
grows the right way.  On my system (68020/30) zprintf will touch
an area beyond the stack base and die when there are only a
few arguments to zprintf.  My confidence in SVVS is low.

This presents a dilemma to us outsiders.  
  1) I can't claim that my port passes SVVS because of the NULL pointers.
	[Anyone who currently claims SVVS conformance is able to
	do so only because they have the same blind spots as a 3B2.  I
	suppose it's possible that fixing SVVS would result in the 3B2
	being unable to pass!  Would AT&T then de-certify it's own system!?]
  2) I can't 'fix' SVVS because then, well I've changed SVVS.  It's
	no good to claim SVVS-like conformance :-)
  3) Should I deliberately introduce errors into my system so that it
	will pass SVVS?  Sorry, no.
  4) It's DAMN hard to get AT&T to provide a waiver (or is it an
	'exception' these days?).  It's even harder to get SVVS changed.

I'd like AT&T to have a good SVVS, and am willing to provide
a list of problems we've run across.

						Ed Rupp
						Motorola, Inc. Austin Tx
						512-440-2224