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=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 6546 invoked from network); 3 Dec 2022 04:43:53 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2022 04:43:53 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1670042633; b=N+ydYxDKqkcNFH0GLgOSx/3hQyaE/6TsU1yyF7xerkwUVovgHCoX9HsdoyRudMa7UN/O4UjWxc MlHYNEdPJjvyGEOQfzSyOIEfwNo9atlOqbxFi3odrrM+cQUrHufVoATfVevOhNJvEmaFSyV7Fo luG86Vlsy2mn34Vmz1D0GjwKx8t/5s3aW6Cnlx0Sg/r75lCIiioknmV8PCKuLe25GRFnpHsJEa Tmk4OvJIurFR5rM0CRjk8+q42ZUicoFrG1Bl0ncMwIEjC2TqHCxjhov5bk2OJ1GotsWKCKkC7D 2+5OHdoG/2IqRLzj2oEamCY8lQtKtxy608Gxl4iCGe5TuA==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f53.google.com) smtp.remote-ip=209.85.217.53; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20210803; t=1670042633; bh=a0ZEDYNmiKJGS+zXdZTozVAElYXbA7qpaQIMgfV1MMw=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=T69OHUmJn6C6AAXf5FZ0EBrulFnPH4Jy2O1aztaDHdqpfsOx6k/OUjlpFI/YFALOZNUJgwfNGP /h4SeBp9JjLXGSlwY64lILUK5SrfMjo7Vf48jxmp1voHcZ5RFys2OC94+S2SP4OcmODuUcRxfb umfNlFtuUQrcJoznZzCA07R9//vZTd/VLfBGNIF/QxCFpLWZr94OHW29eQuOljiNKVmbB1dw8W pt/WdTMOflzFEI9CaRVyX/b+sIXweWL/HtwBo3IXtPWlyNu9NcURjMmxbnzLemR6PlzOAenzNr RAs5zhwId+2CrqKUlk4+mlLyrbtuapF7fJMIyP1OIkhRxA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20210803; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=0mf2q3xlmqcvBB0wCJ1GbKl3QxCy4JNigSv87sE8eu8=; b=AvWg8AFFyUsDIradmFqaClKFUK htVsTOZ567Vm6NOiE91wRJayfUAoh2JbKKuhzQ+orMg9ZX1vIUj4X6GekfiwiOM4yMrwe0bM42H+r Ze3ntKi9PSLAidIO+B9f8B54NY837gmyo/sBJn4Il4AyV0TRNN3MlMlns/oL6xQzxUjBg09M/AZ5v xCgihHoA7S19qZy4CUK+N4h2qerKgPdU3KEF/H6ajNrT+VzHKeM9mzFGi770zzMbAs1DmiZwKkcRN fku7+7TEkb2kP2s1vC0e/Z8zbakAvrubdHhxVEOOLnElgDW8NxZMl11XyaNyCx4cbBIsMwUZS2KsI afeI97Cw==; Received: by zero.zsh.org with local id 1p1KNV-000Kpw-Fn; Sat, 03 Dec 2022 04:43:53 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f53.google.com) smtp.remote-ip=209.85.217.53; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-vs1-f53.google.com ([209.85.217.53]:36455) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1p1GUO-000Bm4-S6; Sat, 03 Dec 2022 00:34:53 +0000 Received: by mail-vs1-f53.google.com with SMTP id c184so6202461vsc.3 for ; Fri, 02 Dec 2022 16:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=0mf2q3xlmqcvBB0wCJ1GbKl3QxCy4JNigSv87sE8eu8=; b=PTW+48C9Ovbm9xc92/phYhgyriWQkve8hzXEmLwLS1hZijSdPIn9i2yZ0beiNvJVPn umrYozbXrdnSRzltqyqvSsxfou6E5N+H927hxxF9KFeQYCn6WFGb+PUEX2DFBfxKzTFn 2zpHBWlWGttbEHlOn7HMh1pR1RMP2KUBPtzmJZ0Qiwp8M5WywvJ9jTXKwXOu/0q01CP8 3fNilXgEvvF8o5Bo/jRMCUDqlWm3HawA2wQOnnoGjXJ7qRj/9HYUBL4OJy9xc47hrB9M KELWqlXB5rnt7gVc1YVl0EC1b25TR0UaWOsysZ+BGobN3Y2SOVqxWsFvpmRODP33AOvh qwuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0mf2q3xlmqcvBB0wCJ1GbKl3QxCy4JNigSv87sE8eu8=; b=BqXGQqCwnLytC56Qhq0CLpJRDwGnMXATYj3Xh3zcU7WjU6j8qi2a/xmNOwTFIcfJe+ Do+A9uPW40rZYPMPFBr+4I7KtWzMXkSgI3GgSuQQAa2FAsvVEnmBucRE6COrFb6PZzBM vurPL6B9A9Yk358E2rrj8I8G3DbojqJIaow9ElgAfujQ0H979W8wL6aKgArgZoTd1khQ HE9USQk7k/4FODfuO9RqWfChGNia4uTAWXM4A5uuKAmbS9rcmtv/YzLlBviX3x0VzvLT 8MDyQ/6lbvvu6CgK2Vv+yU5AXT5bHFT6yAYJj6H9rlL89wcMXHsQEWs3BaWK8s6Vd6pi h0uQ== X-Gm-Message-State: ANoB5pnYGxZIZO38F6KQoqaJ3ivehdNjUuK0VmnKCZZ1htdz6dnuEB1h wwl3DajcPCNIMEK5bFr07DaMP4BbUyXPzJOC2RqzDh54 X-Google-Smtp-Source: AA0mqf7xFEhl/9MQL/5stOud3j5R4qa9g1/c1wCis258U512Aj0eWynafGlTnDHTImDVCkQLQ6Ocw1MRu3OjeFTZgIc= X-Received: by 2002:a67:fe99:0:b0:3b0:f637:6f1a with SMTP id b25-20020a67fe99000000b003b0f6376f1amr5044448vsr.56.1670027683535; Fri, 02 Dec 2022 16:34:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Philippe Altherr Date: Sat, 3 Dec 2022 01:34:32 +0100 Message-ID: Subject: Re: [PATCH] Remove NOERREXIT_UNTIL_EXEC To: Zsh hackers list Cc: Bart Schaefer Content-Type: multipart/mixed; boundary="000000000000d8388205eee19ef3" X-Validation-by: larryv@zsh.org X-Seq: 51098 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: , List-Subscribe: , List-Unsubscribe: , List-Post: List-Owner: List-Archive: --000000000000d8388205eee19ef3 Content-Type: multipart/alternative; boundary="000000000000d8387f05eee19ef1" --000000000000d8387f05eee19ef1 Content-Type: text/plain; charset="UTF-8" Stupid me. I forgot the patch! Here it is. Philippe On Sat, Dec 3, 2022 at 1:31 AM Philippe Altherr wrote: > The noerrexit NOERREXIT_UNTIL_EXEC bit is never set and can therefore be > removed. In other words the patch only removes dead code. > > I have been intrigued by the NOERREXIT_UNTIL_EXEC bit for a while. I > didn't understand its purpose nor why the NOERREXIT_EXIT and > NOERREXIT_RETURN bits wouldn't be enough to solve the problem at hand. > After finally having a closer look, I must admit that I still don't > understand. However, I discovered that the bit is never set and can safely > be removed. More on that below. > > The bit was introduced in commit d6a32dd > , > where the noerrexit value 2 corresponds to today's NOERREXIT_UNTIL_EXEC and > the value 1 to NOERREXIT_EXIT. There was no distinction yet between > NOERREXIT_EXIT and NOERREXIT_RETURN. At that time, there was also no > this_noerrexit variable. The distinction between NOERREXIT_EXIT and > NOERREXIT_RETURN was introduced in commit 97d4bdb > , > which also introduced today's noerrexit bits. > > One thing that distinguishes the NOERREXIT_UNTIL_EXEC bit from the other > noerrexit bits is that it seems intended for the caller(s) of the function > that sets it, while the other bits are intended for the callee(s). This is > similar to today's this_noerrexit variable. I wonder whether this bit was a > first attempt at solving the problem that is solved in today's code by the > this_noerrexit variable. This would explain why everything is still fine > even though the bit is no longer set. > > In today's code, the NOERREXIT_UNTIL_EXEC bit is only ever set in loop.c > at line 578 > . > This line can only be reached if run != 0 && run !=2 && olderrexit == 0 && > lastval == 0. The loop above > can > only be exited at one of the following lines: > > - line 551 > => > run == 0 > - line 557 > > => run == 0 || run == 2 > - line 565 > > => run == 1 && lastval != 0 > - line 568 > > => run == 0 && lastval == 0 > > None of these cases lead to line 578. Thus the NOERREXIT_UNTIL_EXEC bit is > never set and can safely be removed. > > The code "noerrexit &= ~ (NOERREXIT_EXIT | NOERREXIT_RETURN)" at line 580 > can > be simplified into "noerrexit = olderrexit" because NOERREXIT_UNTIL_EXEC > was the only noerrexit bit that was flowing from callees to their caller. > > Obviously all tests still pass. And I checked that the tests introduced by commit > d6a32dd > are > still present. > > I have built this patch on top of my patch > patch-06-fix-eval-and-source-statements.txt but I don't think that it > depends on it nor on any of my previous patches (but I haven't tried to > confirm it). > > QUESTION: Should NOERREXIT_SIGNAL's value > > be changed to 4 (from 8) since the value 4 is no longer used > by NOERREXIT_UNTIL_EXEC? > > Philippe > > --000000000000d8387f05eee19ef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stupid me. I forgot the patch! Here it is.

<= div>Philippe


On Sat, Dec 3, 2022 at 1:31 AM Philippe Al= therr <philippe.altherr@gm= ail.com> wrote:
The noerrexit NOERREXIT_UNTIL_EXEC bit is never set= and can therefore be removed. In other words the patch only removes dead c= ode.

I have been intrigued by the NOERREXIT_UNTIL_EXEC b= it for a while. I didn't understand its purpose nor why the NOERREXIT_E= XIT and NOERREXIT_RETURN bits wouldn't be enough to solve the problem a= t hand. After finally having a closer look, I must admit that I still don&#= 39;t understand. However, I discovered that the bit is never set and can sa= fely be removed. More on that below.

The bit was i= ntroduced in commit d6a32dd, where = the noerrexit value 2 corresponds to today's NOERREXIT_UNTIL_EXEC and t= he value 1 to NOERREXIT_EXIT. There was no distinction yet between NOERREXI= T_EXIT and NOERREXIT_RETURN. At that time, there was also no this_noerrexit= variable. The=C2=A0distinction between NOERREXIT_EXIT and NOERREXIT_RETURN= was introduced in commit 97d4bdb, = which also introduced today's noerrexit bits.

= One thing=C2=A0that distinguishes the NOERREXIT_UNTIL_EXEC bit from the oth= er noerrexit bits is that it seems intended for the caller(s) of the functi= on that sets it, while the other bits are intended for the callee(s). This = is similar to today's this_noerrexit variable. I wonder whether this bi= t was a first attempt at solving the problem that is solved in today's = code by the this_noerrexit variable. This would explain why everything is s= till fine even though the bit is no longer set.

In= today's code, the NOERREXIT_UNTIL_EXEC bit is only ever set in=C2=A0loop.c at line 578. Thi= s line can only be reached if run !=3D 0 && run !=3D2 && ol= derrexit =3D=3D 0 && lastval =3D=3D 0. The loop above=C2=A0can only be exited at one of = the following lines:

- line 551 =3D> run =3D=3D 0
- line 557 =3D> run =3D=3D= 0 || run =3D=3D 2
- line 565 =3D> run =3D=3D 1 && lastval !=3D 0
- line 568 =3D> r= un =3D=3D 0 && lastval =3D=3D 0

None of th= ese cases lead to line 578. Thus the NOERREXIT_UNTIL_EXEC bit is never set = and can safely be removed.

The code "noerrexi= t &=3D ~ (NOERREXIT_EXIT | NOERREXIT_RETURN)" at line 580=C2=A0can be simplified into &= quot;noerrexit =3D olderrexit" because NOERREXIT_UNTIL_EXEC was the on= ly noerrexit bit that was flowing from callees to their caller.
<= br>
Obviously all tests still pass. And I checked that the tests = introduced by=C2=A0commit d6a32dd= =C2=A0are still present.

I have built this patch o= n top of my patch patch-06-fix-eval-and-source-statements.txt but I don'= ;t think that it depends on it nor on any of my previous patches (but I hav= en't tried to confirm it).

QUESTION: Should=C2= =A0NOERREXIT_SIGNAL's= value be changed to 4 (from 8) since the value 4 is no longer used by= =C2=A0NOERREXIT_UNTIL_EXEC?

Philippe

--000000000000d8387f05eee19ef1-- --000000000000d8388205eee19ef3 Content-Type: text/plain; charset="US-ASCII"; name="patch-07-remove-noerrexit-until-exec.txt" Content-Disposition: attachment; filename="patch-07-remove-noerrexit-until-exec.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lb77c9i30 ZGlmZiAtLWdpdCBhL1NyYy9leGVjLmMgYi9TcmMvZXhlYy5jCmluZGV4IDhmZjY0ODllYy4uMWRk NTY5MDE5IDEwMDY0NAotLS0gYS9TcmMvZXhlYy5jCisrKyBiL1NyYy9leGVjLmMKQEAgLTE1NTks MTQgKzE1NTksNyBAQCBleGVjbGlzdChFc3RhdGUgc3RhdGUsIGludCBkb250X2NoYW5nZV9qb2Is IGludCBleGl0aW5nKQogCXN0YXRlLT5wYy0tOwogc3VibGlzdF9kb25lOgogCi0JLyoKLQkgKiBT ZWUgaGFpcnkgY29kZSBuZWFyIHRoZSBlbmQgb2YgZXhlY2lmKCkgZm9yIHRoZQotCSAqIGZvbGxv d2luZy4gICJub2VycmV4aXQgIiBvbmx5IGFwcGxpZXMgdW50aWwKLQkgKiB3ZSBoaXQgZXhlY2Nt ZCBvbiB0aGUgd2F5IGRvd24uICBXZSdyZSBub3cKLQkgKiBvbiB0aGUgd2F5IGJhY2sgdXAsIHNv IGRvbid0IHJlc3RvcmUgaXQuCi0JICovCi0JaWYgKCEob2xkbm9lcnJleGl0ICYgTk9FUlJFWElU X1VOVElMX0VYRUMpKQotCSAgICBub2VycmV4aXQgPSBvbGRub2VycmV4aXQ7CisJbm9lcnJleGl0 ID0gb2xkbm9lcnJleGl0OwogCiAJaWYgKHNpZ3RyYXBwZWRbU0lHREVCVUddICYmICFpc3NldChE RUJVR0JFRk9SRUNNRCkgJiYgIWRvbmVkZWJ1ZykgewogCSAgICAvKgpAQCAtMzI0NiwxMCArMzIz OSw2IEBAIGV4ZWNjbWRfZXhlYyhFc3RhdGUgc3RhdGUsIEV4ZWNjbWRfcGFyYW1zIGVwYXJhbXMs CiAgICAgfSBlbHNlCiAJcHJlYXJncyA9IE5VTEw7CiAKLSAgICAvKiBpZiB3ZSBnZXQgdGhpcyBm YXIsIGl0IGlzIE9LIHRvIHBheSBhdHRlbnRpb24gdG8gbGFzdHZhbCBhZ2FpbiAqLwotICAgIGlm IChub2VycmV4aXQgJiBOT0VSUkVYSVRfVU5USUxfRVhFQykKLQlub2VycmV4aXQgPSAwOwotCiAg ICAgLyogRG8gcHJlZm9yayBzdWJzdGl0dXRpb25zLgogICAgICAqCiAgICAgICogRGVjaWRlIGlm IHdlIG5lZWQgIm1hZ2ljIiBoYW5kbGluZyBvZiB+J3MgZXRjLiBpbgpkaWZmIC0tZ2l0IGEvU3Jj L2xvb3AuYyBiL1NyYy9sb29wLmMKaW5kZXggN2MzZTA0YjhhLi42MTU0M2VkNzMgMTAwNjQ0Ci0t LSBhL1NyYy9sb29wLmMKKysrIGIvU3JjL2xvb3AuYwpAQCAtNTY5LDIzICs1NjksMTQgQEAgZXhl Y2lmKEVzdGF0ZSBzdGF0ZSwgaW50IGRvX2V4ZWMpCiAJcyA9IDE7CiAJc3RhdGUtPnBjID0gbmV4 dDsKICAgICB9CisgICAgbm9lcnJleGl0ID0gb2xkZXJyZXhpdDsKIAogICAgIGlmIChydW4pIHsK LQkvKiB3ZSBuZWVkIHRvIGlnbm9yZSBsYXN0dmFsIHVudGlsIHdlIHJlYWNoIGV4ZWNjbWQoKSAq LwotCWlmIChvbGRlcnJleGl0IHx8IHJ1biA9PSAyKQotCSAgICBub2VycmV4aXQgPSBvbGRlcnJl eGl0OwotCWVsc2UgaWYgKGxhc3R2YWwpCi0JICAgIG5vZXJyZXhpdCB8PSBOT0VSUkVYSVRfRVhJ VCB8IE5PRVJSRVhJVF9SRVRVUk4gfCBOT0VSUkVYSVRfVU5USUxfRVhFQzsKLQllbHNlCi0JICAg IG5vZXJyZXhpdCAmPSB+IChOT0VSUkVYSVRfRVhJVCB8IE5PRVJSRVhJVF9SRVRVUk4pOwogCWNt ZHB1c2gocnVuID09IDIgPyBDU19FTFNFIDogKHMgPyBDU19FTElGVEhFTiA6IENTX0lGVEhFTikp OwogCWV4ZWNsaXN0KHN0YXRlLCAxLCBkb19leGVjKTsKIAljbWRwb3AoKTsKLSAgICB9IGVsc2Ug ewotCW5vZXJyZXhpdCA9IG9sZGVycmV4aXQ7Ci0JaWYgKCFyZXRmbGFnICYmICFlcnJmbGFnKQot CSAgICBsYXN0dmFsID0gMDsKLSAgICB9CisgICAgfSBlbHNlIGlmICghcmV0ZmxhZyAmJiAhZXJy ZmxhZykKKwlsYXN0dmFsID0gMDsKICAgICBzdGF0ZS0+cGMgPSBlbmQ7CiAgICAgdGhpc19ub2Vy cmV4aXQgPSAxOwogCmRpZmYgLS1naXQgYS9TcmMvenNoLmggYi9TcmMvenNoLmgKaW5kZXggNDBm OWVhNTM3Li43MDMyMzFjYTIgMTAwNjQ0Ci0tLSBhL1NyYy96c2guaAorKysgYi9TcmMvenNoLmgK QEAgLTIyMjAsOCArMjIyMCw2IEBAIGVudW0gbm9lcnJleGl0X2JpdHMgewogICAgIE5PRVJSRVhJ VF9FWElUID0gMSwKICAgICAvKiBTdXBwcmVzcyBFUlJfUkVUVVJOOiBwZXIgZnVuY3Rpb24gY2Fs bCAqLwogICAgIE5PRVJSRVhJVF9SRVRVUk4gPSAyLAotICAgIC8qIE5PRVJSRVhJVCBvbmx5IG5l ZWRlZCBvbiB3YXkgZG93biAqLwotICAgIE5PRVJSRVhJVF9VTlRJTF9FWEVDID0gNCwKICAgICAv KiBGb3JjZSBleGl0IG9uIFNJR0lOVCAqLwogICAgIE5PRVJSRVhJVF9TSUdOQUwgPSA4CiB9Owo= --000000000000d8388205eee19ef3--