att & osf

[Daniel R. Levy]

In article <1988Aug5.211217.21037 at utzoo.uucp>, henry at utzoo.uucp (Henry Spencer) writes:
# In article <3396 at vpk4.UUCP> scott at attcan.UUCP (Scott MacQuarrie) writes:
# >> this is really laying it on a bit too thick.  There are many things AT&T
# >> could have done to make hardware independence easier, and they have done
# >> very few of them. 
# >System V Unix runs on a variety of equipment which is not manufactured with
# >or by AT&T. Your arguement that SYSV or SYSV-compatible operating systems only
# >run on AT&T equipment is simply wrong.
# 
# That's not what I said, and not what I meant.  I didn't say it would not run
# on non-AT&T equipment; I said AT&T was making no serious attempt to make it
# easy to port it to non-AT&T equipment.  Last time I looked, SysV still had
# quite a bit of code that dereferences NULL pointers, a known portability
# problem (and coding error) that AT&T has made no effort to fix.  You were
# the one claiming that they were bending over backwards to make it portable;
# well, when are they going to fix the NULL-pointer bugs?

Henry, you're the one who seems to be whomping the straw man now.  If
MacQuarrie ever "claim[ed] that [AT&T is] bending over backwards to make
[System V] portable" I sure missed it, and can't find it in a few days' worth
of comp.unix.wizards here.  The most I recall seeing was a denial of what
appears to have been an insinuation on your part that AT&T is trying to keep
its code NONPORTABLE.  Please feel free to mail me a copy of the "smoking gun"
if you have it.

By the way, code which dereferences NULL pointers hurts some AT&T hardware too
(i.e., the 3B20, which doesn't have a 0 byte at location 0 in the process
space).  Somehow, several releases of System V have been brought up on it
just the same and work great.  Must be a fluke.

Incidentally, I know of no provision in the AT&T System V license which says
that if you wish to port System V to a new base, that you may not fix any
problems in the code even though the result still meets the SVID.  If you
know otherwise, please feel free to quote chapter and verse.

Oh yes, since you're, well, not exactly entranced with SUN's partnership with
AT&T, let me point out in respect to the very issue you complained about, both
the Sun-3 and Sun-4 don't like *((char *)0).  They get a memory fault from that
(I tried it using /usr/5bin/cc, the System V universe SUN C compiler).  If AT&T
is trying to keep System V unportable by keeping the dereference of NULL in its
code, then it is hurting SUN's ports of future releases of System V.

Anyone with reason would conclude that it's in AT&T's financial interest
(GAA, there's that DIRTY word again :-) to have quality code, and that poor
quality code can only hurt AT&T.  If you're going to hint at a conspiracy,
you're going to have to come up with other evidence than code bugs.

By the way, I am only talking as an interested party.  I'm in CAD tool support,
not UNIX system development, and I do not purport to speak for AT&T itself.
-- 
|------------Dan Levy------------|  THE OPINIONS EXPRESSED HEREIN ARE MINE ONLY
| Bell Labs Area 61 (R.I.P., TTY)|  AND ARE NOT TO BE IMPUTED TO AT&T.
|        Skokie, Illinois        | 
|-----Path:  att!ttbcad!levy-----|