Path: utzoo!dciem!nrcaer!scs!spl1!laidbak!att!ttrdc!levy From: levy@ttrdc.UUCP (Daniel R. Levy) Newsgroups: comp.unix.wizards Subject: Re: att & osf Message-ID: <2843@ttrdc.UUCP> Date: 7 Aug 88 04:59:56 GMT Article-I.D.: ttrdc.2843 References: <4964@killer.DALLAS.TX.US> <3395@vpk4.UUCP> <1988Aug5.211217.21037@utzoo.uucp> Organization: AT&T, Skokie, IL Lines: 54 Summary: I disagree. In article <1988Aug5.211217.21037@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes: # In article <3396@vpk4.UUCP> scott@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-----|