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 6385 invoked from network); 3 Dec 2022 04:42:46 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2022 04:42:46 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1670042566; b=gDlqa8QHldCTxCbH8sOOFa6QPePE8/lqc6XonTOTHk4y8rB1fnyh5l/39DnNqKNvPNurhfUyCv uO3CFIAhDWc7Tcy94i7bGJFVYDgL6solb4pikaupvZCPY+7KFq5FJ8OxnMcTYSU9HZF3TO6YDj HViapb9O08KCex+tUXMaGhIDIODj3z69re6568P+1r4Q8oa3yHj8JJ/EYH9FwexjFh8f10fWxb /K/C0KW+oEHxtLLIyV/ZROIsFtQIf4Ynp7QiPYNaVHypEhX2qvUtL2hvMad9s8MrFN95x5VQg9 sTYWrFi+e7x+mVgPAIGAp2GqSRcZb5944F9DVG1jkfhpAg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f54.google.com) smtp.remote-ip=209.85.217.54; 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=1670042566; bh=+ng4Hbu8N7mNXae2Xb1LRlRK3r3ycZRRZPD7CLF1oHg=; 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:MIME-Version: DKIM-Signature:DKIM-Signature; b=UjMeGeIXpF0gkBMSOGj9tDm30MciRX7uja/HCfRVEMq3p4lUadVP/oCFnAF5+Yfo45rmja5lWH 8sFX3ZFvuFAE5gscRNrQ5oi+C667vrA05ch3Q7g/y+gvhL3ucL8ZMH7BTa2HvHTOZOC9YRdU8A Ex0+BVRugpFZZhidOwusgxthgFwr8pC54m1EJP35lP1ocK2VA8AX9rF0RrJXwvhm6+JzSbXzW+ QQJPlSWrUFM/4+ibJqxvwNFWnxPXN42c+KKXB4ZoLdAKYAsixrXjjx44JJT5RslPWBc2TBa3xk 35+TOpqJAb/SIrihIhVDSAMfuiqQkkkmrSAH6JtKZ/9Gng==; 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:MIME-Version:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References; bh=+ng4Hbu8N7mNXae2Xb1LRlRK3r3ycZRRZPD7CLF1oHg=; b=L+nDCCUxO/F9mCNi4kBYUi3Qx7 V3i/SH2DKanJMbqeoPrk+OXMJ4Q2Xd/yExl54gryR5NgteejC3VXZHBt2KW572Q5lGs4DXv+cCWTT C14Ov6DNDL9SMIs4p6PcjTq8xMfGg/KSW98ej198geHRss5NptGz6sUTmsik95pBFQDF+Y4UYaVF/ J4QVuB5JbIDKLIVJwrX3Yu523kti8r2Nk9b+kcifsF3Hwbfz3eByTK770J0N1MWttf4lwS6L9wcl7 aWnW5v3jDqLm+7E2WigJFBr9atu+eT+gMywa4EKc5uyF3+RDDKVye25eMBebEcRJaOuP9z+EFngBn Z9nlzKOg==; Received: by zero.zsh.org with local id 1p1KMP-000KCh-8D; Sat, 03 Dec 2022 04:42:45 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f54.google.com) smtp.remote-ip=209.85.217.54; 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-f54.google.com ([209.85.217.54]:46774) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1p1GR5-000Bgd-S7; Sat, 03 Dec 2022 00:31:28 +0000 Received: by mail-vs1-f54.google.com with SMTP id q128so6152061vsa.13 for ; Fri, 02 Dec 2022 16:31:19 -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:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=+ng4Hbu8N7mNXae2Xb1LRlRK3r3ycZRRZPD7CLF1oHg=; b=W8zlp4VTiSJwHWrI0+aHu3PIx7P0qwtxKS/M1V/dB4tqDza0jlLWsNtSuqcomBUb1W DQAzBq5Hr6dpBZzhDsQzNdnyAzZYfe38HpgEiSdgtKoLIHFwJ7iJiyUGsHunnDXgCQEB HR8Kja+Jiq4oHAaTd/ONfdfKF28lqRWPdXlLRrEJmuKZulX5+hK5qV9nVssEexTKIfXb k5ZxvS5y7tckfjRuSs/abLjGW7VsW2uB+s7bvGdwYJQfI7S8yNEjsGA6Y6vWPuwIhw1R n3plzqZqzXFV5NzU6J2vbpC+51JghQzgiDNr5V7H5yA+36+saI6QxiSkMsz1TRiDH9Pb 4UxA== 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:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=+ng4Hbu8N7mNXae2Xb1LRlRK3r3ycZRRZPD7CLF1oHg=; b=ewMW+BAEHx5R4vOFspHiGbrZeaB1+Y0w+q6COYi/I38LV70GOOMa9oZeae+k9ZS9Bd b4AFwx/WU/deAx/aYQhbZnfCT4CISANhrT4ungeOix9wF8+e5b/dZujdm86hyDMBAOMF yGpQo/Ib4ccLDWx194kot2d3vcgLlSJznnxX80Dus5EC86Fw1AZ9p/0WavC9n7zzlgtv 1YxlUhJvPGfSZhhAoJTac72Yz6JQlIeMXFqD8t/5Z863f2Vqf8lh0kvxW07Vfrn977xF pwso3vasCwLUleZPfzGLB9lFjaZIT3mBBX5ww8hrFRbGxIp5lOi3Ten0F9xDsm5QGhf8 I3pw== X-Gm-Message-State: ANoB5pl4nzgwufQkJWT6gwc1sXrtl2RvvF3hWtscBhkawzTqyegiPwHp 9IPYJmeCJW6Jd263KUPsxLTZoYTYlxaRBE/KCHGHu6FE8bY= X-Google-Smtp-Source: AA0mqf60WOHbSelrzlZgQwwEdPl8Ys3M69ZAJGVN9QAD4mCwyVIBMhk150DSN1i2fkZAjgxkvBMtkvtM5iywYSSZlf8= X-Received: by 2002:a67:fe99:0:b0:3b0:f637:6f1a with SMTP id b25-20020a67fe99000000b003b0f6376f1amr5040551vsr.56.1670027478262; Fri, 02 Dec 2022 16:31:18 -0800 (PST) MIME-Version: 1.0 From: Philippe Altherr Date: Sat, 3 Dec 2022 01:31:07 +0100 Message-ID: Subject: [PATCH] Remove NOERREXIT_UNTIL_EXEC To: Zsh hackers list Cc: Bart Schaefer Content-Type: multipart/alternative; boundary="0000000000009b698205eee19275" X-Validation-by: larryv@zsh.org X-Seq: 51097 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: --0000000000009b698205eee19275 Content-Type: text/plain; charset="UTF-8" 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 --0000000000009b698205eee19275 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The noerrexit NOERREXIT_UNTIL_EXEC bit is never set and ca= n 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 un= derstand. However, I discovered that the bit is never set and can safely be= removed. More on that below.

The bit was introduc= ed in commit d6a32dd, where the noerrexit value 2 cor= responds to today's NOERREXIT_UNTIL_EXEC and the value 1 to NOERREXIT_E= XIT. There was no distinction yet between NOERREXIT_EXIT and NOERREXIT_RETU= RN. At that time, there was also no this_noerrexit variable. The=C2=A0disti= nction between NOERREXIT_EXIT and NOERREXIT_RETURN was introduced in commit 97d4bdb, which also introduced today's noerrexit= bits.

One thing=C2=A0that distinguishes the NOERR= EXIT_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 i= ntended for the callee(s). This is similar to today's this_noerrexit va= riable. I wonder whether this bit was a first attempt at solving the proble= m that is solved in today's code by the this_noerrexit variable. This w= ould 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=C2=A0loop.c at lin= e 578. This line can only be reached if run !=3D 0 && run !=3D2= && olderrexit =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 && lastv= al !=3D 0
- line 568 =3D> = run =3D=3D 0 && lastval =3D=3D 0

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

The code "noerrex= it &=3D ~ (NOERREXIT_EXIT | NOERREXIT_RETURN)" at line 580=C2=A0can be simplified into "noerrexit = =3D olderrexit" because NOERREXIT_UNTIL_EXEC was the only noerrexit bi= t that was flowing from callees to their caller.

O= bviously all tests still pass. And I checked that the tests introduced by= =C2=A0commit d6a32dd=C2=A0are still present.

I have built this patch on top of my patch patch-06-fix-ev= al-and-source-statements.txt but I don't think that it depends on it no= r on any of my previous patches (but I haven't tried to confirm it).

QUESTION: Should=C2=A0