Path: utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!olivea!oliveb!felix!ccicpg!hobbit!ndjc From: ndjc@hobbit.UUCP (Nick Crossley) Newsgroups: comp.bugs.sys5 Subject: Re: Nasty bug in release 4 Bourne shell Summary: Don't know about AT&T SPARC reference source Keywords: Bourne shell, exec, redirection Message-ID: <10518@hobbit.UUCP> Date: 10 Jan 91 02:48:59 GMT References: <9233@hobbit.UUCP> <5048@auspex.auspex.com> Organization: ICL North America, Irvine, CA 92718 Lines: 44 In article <5048@auspex.auspex.com> guy@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@ccicpg.UUCP