gwyn@smoke.ARPA (Doug Gwyn ) (08/28/88)
In article <1988Aug26.194505.25724@utzoo.uucp> 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"? I think one of the reasons that bugs have persisted for a long time in UNIX System V products is that it is a major hassle getting one removed. It was not considered acceptable (I was told by a vendor doing a "validated port") to simply quietly fix a bug; instead EVERY change to the source code had to be thoroughly documented and justified. The kind of people who are best at idenitifying and fixing portability bugs are probably not eager to spend a lot of effort on such trivial matters, so as a result they don't bother to fix the problems UNLESS they have to (because their system is directly affected). That's another managerial problem..
ed@oakhill.UUCP (Ed Rupp) (08/31/88)
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
henry@utzoo.uucp (Henry Spencer) (08/31/88)
In article <8391@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) 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"? Uh, Doug, SVVS, not SVID. The SVVS is a great pile of source code for checking SVID compliance. And I have it on good authority that it does indeed have null-pointer problems. >I think one of the reasons that bugs have persisted for a long time in UNIX >System V products is that it is a major hassle getting one removed... Yes, I've heard this as well, and I believe it. "Source code control" with a vengeance! :-) -- Intel CPUs are not defective, | Henry Spencer at U of Toronto Zoology they just act that way. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
greywolf@unisoft.UUCP (The Grey Wolf) (09/01/88)
In article <8391@smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <1988Aug26.194505.25724@utzoo.uucp> 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"? Who was talking about SVID ? The SVVS is not the same thing as the SVID. SVVS is the System V Verification Suite. It has to test things within the SVID to make sure that they work properly, i.e. it tests an INTERFACE SPEC. The Test Suite itself is a PROGRAM, and it probably has NULL POINTER PROBLEMS. [I've had to count to ten after reading your posts more than once.] -- " Roan Anderson, Software Engineer, Configuration Management UniSoft Corporation, Emeryville, CA. *** The above opinions are my own and not those of my employer. ***
gwyn@smoke.ARPA (Doug Gwyn ) (09/01/88)
In article <1269@unisoft.UUCP> greywolf@unisoft.UUCP (The Grey Wolf) writes: >Who was talking about SVID ? The SVVS is not the same thing as the SVID. Yes, sorry -- I misread Henry's posting. I can well believe the SVVS has null pointer problems, among others. It certainly is harder to excuse in the SVVS than in the UNIX System V product.
henry@utzoo.uucp (Henry Spencer) (09/14/88)
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