From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2830 invoked from network); 30 Dec 2022 19:57:43 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 30 Dec 2022 19:57:43 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 02A2842399; Sat, 31 Dec 2022 05:57:39 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1672430259; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=47YTH/mH5bgRMnJbWpQFhYniDkUZ7qBTHLd3Od95C6M=; b=yI4CScv2gKUw+kdiQtlI2Aa11vAGBhT+TZqKn7TUEGlURMdLQBByBkszVAIacM90ZT8lYG ToUBwuLckft6qVpVP9e4k9XE6GdbKkznbSSVq9DfYK/B2vAensr2YQDs9WUA2KdmkAc7p5 GznFNvOK4gmztsfN1Flwuql0te0S2dI= Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by minnie.tuhs.org (Postfix) with ESMTPS id A452542398 for ; Sat, 31 Dec 2022 05:57:34 +1000 (AEST) Date: Fri, 30 Dec 2022 19:57:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1672430252; x=1672689452; bh=47YTH/mH5bgRMnJbWpQFhYniDkUZ7qBTHLd3Od95C6M=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=q43xOFzH0RV3inJaEDlTG0YYMLAZwBrNVz2yVMvo7tEtpO87AYD5231YKbn5TX0oL 0lprBCpCP1qQ+JiHYx/2ouKmjznMd8e2HIEQtT8sE77ETTHTQ31R/MVkts3W20e79s Cm+qu/AIfKx7Wn59XJAn9B0dFhQwQxOcTSwj4fx/tiEO8e+sGeAK16f/9HuwXa4vkP xizs6AltjWiLfdwGvBUnNLc1JFmvnYr6Hvu2Ny1rFFDR2PvOxl4V9bgy/UGEKOpiLk Jy4AR9talr5nYoTfgbbJ3xAnAQABy0FBn5CSS6hpOPhu22C+P90idILGMG4jOE3sKO GU32dX7diRn6g== To: Paul Ruizendaal Message-ID: In-Reply-To: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> References: <52FB6638-AEFF-4A4F-8C2E-32089D577BA0@planet.nl> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: IXIP4LJCXKRMU4CL2GBPCWKMHZG6R7UM X-Message-ID-Hash: IXIP4LJCXKRMU4CL2GBPCWKMHZG6R7UM X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: A few comments on porting the Bourne shell List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco I'll have to double check later but I'm fairly certain the remaining L/R ch= eats are gone by SysV. From what I can tell much of that portability work = may have been done prior to the V7 release code base we're familiar with, a= s I did some comparison and found only one significant change between V7 an= d 32V code as I know it at least. Either the claims of portability issues = came between 32V and System III (meaning the shell was accepted as "broken"= ? in 32V) or the code we actually see in V7 has already been tidied up sign= ificantly and doesn't represent the "non-portable" version lamented in the = famous quote. Does this observation hold with reality? Is there an earlie= r, more PDP-11 bound version of the Bourne Shell out there? I seem to reca= ll reading something about some bits of it even being in assembly at one po= int, but can't remember the quote source. - Matt G. ------- Original Message ------- On Friday, December 30th, 2022 at 10:25 AM, Paul Ruizendaal = wrote: > London and Reiser report about porting the shell that =E2=80=9Cit require= d by far the largest conversion effort of any supposedly portable program, = for the simple reason that it is not portable.=E2=80=9D By the time of SysI= II this is greatly improved, but also in porting the SysIII user land it wa= s the most complex of the set so far. >=20 > There were three aspects that I found noteworthy: >=20 > 1. London/Reiser apparently felt strongly about a property of casts. The = code argues that casting an l-value should not convert it into a r-value: >=20 > >=20 > /* the following nonsense is required > * because casts turn an Lvalue > * into an Rvalue so two cheats > * are necessary, one for each context. > */ > union { int _cheat;}; > #define Lcheat(a) ((a)._cheat) > #define Rcheat(a) ((int)(a)) > >=20 >=20 > However, Lcheat is only used in two places (in service.c), to set and to = clear a flag in a pointer. Interestingly, the 32V code already replaces one= of these instances with a regular r-value cast. So far, I=E2=80=99d never = thought about this aspect of casts. I stumbled across it, because the Plan = 9 compiler did not accept the Lcheat expansion as valid C. >=20 > 2. On the history of dup2 >=20 > The shell code includes the following: >=20 > >=20 > rename(f1,f2) > REG INT f1, f2; > { > #ifdef RES /* research has different sys calls from TS */ > IF f1!=3Df2 > THEN dup(f1|DUPFLG, f2); > close(f1); > IF f2=3D=3D0 THEN ioset|=3D1 FI > FI > #else > INT fs; > IF f1!=3Df2 > THEN fs =3D fcntl(f2,1,0); > close(f2); > fcntl(f1,0,f2); > close(f1); > IF fs=3D=3D1 THEN fcntl(f2,2,1) FI > IF f2=3D=3D0 THEN ioset|=3D1 FI > FI > #endif > } > >=20 >=20 > I=E2=80=99ve check the 8th edition source, and indeed it supports using D= UPFLG to signal to dup() that it really is dup2(). I had earlier wondered w= hy dup2() did not appear in research until 10th edition, but now that is cl= ear. It would seem that the dup of 8th edition is a direct ancestor to dup(= ) in Plan 9. I wonder why this way of doing things never caught on in the o= ther Unices. >=20 > 3. Halfway to demand paging >=20 > I stumbled across this one because I had a bug in my signal handling. Fro= m early days onwards, Unix supported dynamically growing the stack allocati= on, which arguably is a first step towards building the mechanisms for dema= nd paging. It appears that the Bourne shell made another step, catching pag= e faults and expanding the data/bss allocation dynamically: >=20 > >=20 > VOID fault(sig) > REG INT sig; > { > signal(sig, fault); > IF sig=3D=3DMEMF > THEN IF setbrk(brkincr) =3D=3D -1 > THEN error(nospace); > FI > ELIF ... > >=20 >=20 > This was already present in 7th edition, so it is by no means new in 32V = or SysIII -- it had just escaped my attention as a conceptual step in the d= evelopment of Unix memory handling. >