att & osf

[Henry Spencer]

In article <2843 at ttrdc.UUCP> levy at ttrdc.UUCP (Daniel R. Levy) writes:
>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...

Lest we forget, his actual words were:

	... show me another vendor which has worked as hard to provide
	a truly hardware independent operating system to allow customers
	to feely decide what hardware they need to solve their problems...

>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...

If I'm not mistaken, the 3B20 may not have a 0 at 0, but it does permit
accesses to location 0.  And yes, there are things in System V that break
if this isn't possible.

>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.

There is no legal requirement to avoid fixing code problems.  However, a
lot of people get really tired of doing it over and over again in each
new release of System V.  My understanding is that AT&T has, in the past,
taken the position that *NULL is a problem with those other, inferior,
machines, and not a bug in the AT&T code.

>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)...

Quite true, and in fact Sun did most of the work on cleaning up the *NULL
problems in 4BSD.  AT&T is probably going to have to get its act together
on this issue now that it is committed to support Sun hardware; about time!

>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.

Actually, I don't think this was a deliberate effort to keep SysV unportable,
just a convenient happenstance that AT&T didn't see any reason to do anything
about.  Much of this unwillingness was probably the result of management
stupidity -- simply not realizing that *NULL is a bug even if the machine
doesn't object to it -- rather than deliberate sinister intent.

>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.

To rephrase:  "never ascribe to malice what can be adequately explained
by stupidity".  I'm not suggesting conspiracy, rather the combination of
stupidity and sheer lack of concern for the problems of non-AT&T machines.
Anyone with reason would indeed conclude that fixing bugs is in AT&T's best
interests, but reason is in much shorter supply in this business than many
people realize.  Spending money and resources fixing bugs that aren't making
trouble today (except for one's competitors) requires a long view and quite
a bit of determination, not things that the computer side of AT&T management
has been noted for.  (Sort of odd, since the telephone side is -- or at least
used to be -- quite accustomed to planning decades ahead.)
-- 
MSDOS is not dead, it just     |     Henry Spencer at U of Toronto Zoology
smells that way.               | uunet!attcan!utzoo!henry henry at zoo.toronto.edu