🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.bugs.sys5
Article #282

Re: Nasty bug in release 4 Bourne shell

#282
From: Nick Crossley
Date: Thu, 10 Jan 1991 02:48
44 lines
2902 bytes
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
Technical Details
Message-ID: <10518@hobbit.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!watserv1!watmath!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!samsung!olivea!oliveb!felix!ccicpg!hobbit!ndjc
References: <andy.662338820@xwkg> <9233@hobbit.UUCP> <5048@auspex.auspex.com>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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: <andy.662338820@xwkg> <9233@hobbit.UUCP> <5048@auspex.auspex.com>
Organization: ICL North America, Irvine, CA 92718
Lines: 44