Nasty bug in release 4 Bourne shell
Nick Crossley
ndjc at hobbit.UUCP
Thu Jan 10 13:48:59 AEST 1991
In article <5048 at auspex.auspex.com> guy at auspex.auspex.com (Guy Harris) writes:
>So if it was fixed by somebody working on the SPARC version, has that
>fix been sent back to AT&T?
Unfortunately, I don't know the answer to that (yet). ICL did send
(nearly) complete V.4 SPARC source code with bug fixes back to
AT&T, and then AT&T took that over to produce the SPARC reference
source, making various other changes of their own. For various
silly reasons, we do not yet have a copy of that reference source
here in Irvine. (The "nearly" bit is because there are some
proprietary additions not part of the common V.4 source, such as
our multiprocessor code). If the bug was found and fixed after the
reference source handover, then it is likely that it has not been sent
to AT&T. The best I can do is diff the ICL and AT&T versions when we
get the latter.
> The theory is, after all, that V.4 is V.4
>is V.4; I wouldn't want to have to choose a processor for my desktop
>based on which versions of some bit of processor-independent code got
>into the official releases for various processors.
>
>Who is the "keeper" of the various V.4 ports to the "major"
>microprocessors? Does USL keep them all in-house - in which case one
>would hope that they would have a *single* source tree for all of them,
>with machine-independent code *including* most of the kernel shared
>between all processors, or at least that they'd be working on doing so -
>or are some of them only in the hands of the organization that did the
>port and their customers?
This whole area does seem a little weak to me. There are some
areas of the source tree which are radically different from one
port to another, to the extent of offering completely different
facilities. (One such area is the compilation system; for example,
the current SPARC version does not support COFF, and has a radically
different C code generator and optimiser from the other machines).
I believe that most of the porting groups have sent their code back
to AT&T, but there does appear to be some delay in the merging of
these - if indeed AT&T have any intent of doing such a merge.
--
<<< standard disclaimers >>>
Nick Crossley, ICL NA, 9801 Muirlands, Irvine, CA 92718-2521, USA 714-458-7282
uunet!ccicpg!ndjc / ndjc at ccicpg.UUCP
More information about the Comp.bugs.sys5
mailing list