null pointer problems and AT&T (was: att & osf)

[Ed Rupp]

gwyn at brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
>henry at 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