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 15282 invoked from network); 3 Dec 2022 01:21:51 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 3 Dec 2022 01:21:51 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1670030511; b=OnSg6wFdcuzFbX4xhGDTzI5cg+XdKU6eQ3upYnzweyzzsqIUEw3vgzFJKUVZKxZPpbgQWVHLF+ iuPvwGPlxksPzDyrKm4frYfxSaqMhCo9PiHgpaV1TA1ExCg8kXWUruoKI/Iq7yGlWI/10rySVG ld+s67g8QBxCWRbPmk35xUSLCNtxYInKZ2/xINZDkX56SS5HnZmpnDjaCVOl7ngryq/Di+KBZL cvanBvmVSe8vCPsJ0VBUUHsFaXBT7IH1MqdisNC+j8hCF/DVffALqESJag7eXNXxpdsA0iO5Z4 Gm8SJAxonZSShnBfTT7WfnFDo5c/jtRve2kojZedebFE4Q==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-vs1-f44.google.com) smtp.remote-ip=209.85.217.44; 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=1670030511; bh=Qfsflp5CfOTTTV17IKZ88QWbpUASU3rh3CvlFyh3MRk=; 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=ZBvgt3w9h5zRjyuPYO2gUO9E5buC1ey/B4bHyJSLWcN0HYr8GP6nf9EvTcxznBZvNyoeWQmkG+ uKj12hL10T7rysDvIVXfuHDzSLkw620XKvvT6Aw2h+JdNqZ0+vuNFlaRApWSAnYxedAGAEXQUz Y14CIi9qd+rch5JFqsjknakZidFTp/E+VgAMCuC6YMGnkMd3ENGgSzmrJwd/jeLeTnv/bzx9Rf IUL6z80/Q0zCMy6VAbitty5okVC7JexRr3WPuKDmMJxoVnKsj6OhQZ7bG/4yvwWjg3+ofSWIjJ JkP4E8wgdod9AfHFhTMmkvBDOBy1Gw0Er/8yNO1osBJWWQ==; 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=ytDxtgWthfSdhFP2qsg0mUDeGlCe2AuajDdssfhd8Kk=; b=YOqil/a+XqcWwcuDg9I/YmH2j2 V4t4gPNMKohn4BxkwL3NQMMMeG17g23vKgame5151OTPbie8fU5JXs/VP3r6xMWXNkzW2orKut6U8 soZYtBGKURpzUKHwT5RJEOVkontVNxlJKDrGwXz3rfPKRf1NgDdfqrLy8fCyv69jUT7BRBiOiq40a XhX55Y2ComD5HMUaMYP5zILpC0wq1GLDyLAICP9ZdOHlRAydcj0PQ4Lv53I5t6u5hmoxYxFhzZA9P Nbhdakdl3+OlMJkfvL9G8TOEIXSf6g/Kwruz6fGBIncmvC/pXvQD8Nuj0BCkFL0ybUXxHZQK1zEZ5 Co9ge9sA==; Received: by zero.zsh.org with local id 1p1HDz-000D83-2p; Sat, 03 Dec 2022 01:21:51 +0000 Authentication-Results: zsh.org; iprev=pass (mail-vs1-f44.google.com) smtp.remote-ip=209.85.217.44; 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-f44.google.com ([209.85.217.44]:36706) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1p1HDH-000CnJ-Nk; Sat, 03 Dec 2022 01:21:15 +0000 Received: by mail-vs1-f44.google.com with SMTP id c184so6264320vsc.3 for ; Fri, 02 Dec 2022 17:21:07 -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=ytDxtgWthfSdhFP2qsg0mUDeGlCe2AuajDdssfhd8Kk=; b=CZo9n1CdZFi/DIYEwY/vbYz/dWszb/atEP351dEEuSOtxfSblqd3ZEMnkhGFcl9Vby HeaptB1x6ZkLf0PNwswsdcribFb038djHsszafeSIc9DIuplLUvqbKWRN6TyaL7mQ4e+ b8WrYHH7fsAzCC7dT+Oz26C5Ks8uWcibvWX8pHqfIqSloTwT5zvXuUcOpO4PBuRUgoO5 sy0AAB9xwt9CIZK7Hn+Je929efVzw6Qv1AJiqV7u2RDbeIP+qwCRIp0OpMP9e5UWUYKE L5fZt40IDP0y5tFZIPVyvDKR4TcejyIREHkygigbA/CckZ49Dym2wlbv9FrjdT4ayFIU lPXg== 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=ytDxtgWthfSdhFP2qsg0mUDeGlCe2AuajDdssfhd8Kk=; b=55PTex98v1wYtPpINkdWTRiTNqVC5yw3srjWRVUu6zD8xRn38drlyB6MPfd/ROTFi7 mW6UPlEDa8q4WbaQSYyEU3zZs+zmyXDwa6Fa8+zDgyVFPDQVv632QfUxfSaPycHl8url UGOSSyc0HxqxL/OWR2RwVihE2ZKmP8AsjI4APq2wiFtReZ4dCBcL2b7WrsEZ+PClao77 mclxfodvduIbCuJhiPZa7UH+1lHERHxzDL2mHMWjiz4W+qDoAiN2UGwkNwxSJhT8tlZG 3EXSeLbYESwquUNViY8kQzQcviQobBTPf1nP0msOwQaXv1wueseIx3HixpdKMRq0mMJt 9I/g== X-Gm-Message-State: ANoB5pl9gV2A7SaPIcgbh+nyIyQZR3+M7zBT0IT/Ed0CleaHJ4mM8qjy 64nJtpzXi97q9U8G/n7NcVlLYaSON4T2ll9FHyvNI1Lospg= X-Google-Smtp-Source: AA0mqf5RBPMEAbEUfYxvLpEGRSLgRhBRE0FFJ+TwvYscCl01J7XsqYf669LjhO6SRmSalBHzvRTBpREPBO9VsU35Rl0= X-Received: by 2002:a67:fe99:0:b0:3b0:f637:6f1a with SMTP id b25-20020a67fe99000000b003b0f6376f1amr5091383vsr.56.1670030466343; Fri, 02 Dec 2022 17:21:06 -0800 (PST) MIME-Version: 1.0 From: Philippe Altherr Date: Sat, 3 Dec 2022 02:20:55 +0100 Message-ID: Subject: [PATCH] Use or-assignments to set noerrexit bits To: Zsh hackers list Cc: Bart Schaefer Content-Type: multipart/mixed; boundary="000000000000b5f91a05eee244b4" X-Seq: 51094 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: --000000000000b5f91a05eee244b4 Content-Type: multipart/alternative; boundary="000000000000b5f91605eee244b2" --000000000000b5f91605eee244b2 Content-Type: text/plain; charset="UTF-8" Currently execif uses an or-assignment to set the NOERREXIT_EXIT and NOERREXIT_RETURN bits. Other places, like for example execwhile , use a plain assignment. This looks wrong because if any other noerrexit bits are present, they would inadvertently be lost. Currently there is only one other noerrexit bit that is ever set: NOERREXIT_SIGNAL. It is set in init.c here and here . In both cases it seems to only affect the execution of initialization scripts. The fourth noerrexit bit NOERREXIT_UNTIL_EXEC is never used. For more details on this, see the discussion of my other patch that removes this bit. Thus, in regular code, it's currently impossible to observe a difference between or-assignments and plain assignments. However, it's certainly possible to build examples with well placed sleep statements inside if and while conditions in initialization scripts such that a SIGINT triggers different behaviors depending on whether it's caught in the middle of an if condition or in the middle of a while condition, which sounds wrong. Furthermore, if new noerrexit bits are ever added, the current plain assignments would most likely become problematic. For these reasons, I think it's best to systematically use or-assignments to set noerrexit bits (and and-assigments, like in "noerrexit &= ~NOERREXIT_RETURN" to remove them, which is already the case today). Restoring bits to their prior state, like in "noerrexit = olderrexit", should keep using plain assignments. This patch is built on top of my patch patch-07-remove-noerrexit-until-exec.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). Philippe --000000000000b5f91605eee244b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Currently execif uses = an or-assignment=C2=A0to set the NOERREXIT_EXIT and NOERREXIT_RETURN bits. = Other places, like for=C2=A0example execwhi= le, use a plain assignment. This looks wrong because if any other noerr= exit bits are present, they would inadvertently=C2=A0be lost.

Currently there is only one other noerrexit bit that is ever set:=C2= =A0NOERREXIT_SIGNAL. It is set in init.c here and here. In both cases= it seems to only affect the execution of initialization scripts.

The fourth noerrexit bit=C2=A0NOERREXIT_UNTIL_EXEC is = never used. For more details on this, see the discussion of my other patch = that removes this bit.

Thus, in regular code= , it's currently impossible to observe a difference between or-assignme= nts and plain assignments. However, it's certainly possible to build ex= amples with well placed sleep statements inside if and while conditions in = initialization scripts such that a SIGINT triggers different behaviors depe= nding on whether it's caught in the middle=C2=A0of an if condition or i= n the middle of a while condition, which sounds wrong. Furthermore, if new = noerrexit bits are ever added, the current plain assignments would most lik= ely become problematic.

For these reasons, I think= it's best to systematically use or-assignments to set noerrexit=C2=A0b= its (and and-assigments, like in "noerrexit &=3D ~NOERREXIT_RETURN= " to remove them, which is already the case today). Restoring bits to = their prior state, like in "noerrexit =3D olderrexit", should kee= p using plain assignments.

This patch is built on= =C2=A0top of my patch=C2=A0patch-07-remove-noerrexit-until-exec.txt=C2=A0bu= t I don't think that it depends on it nor on any of my previous patches= (but I haven't tried to confirm it).

Philippe=

--000000000000b5f91605eee244b2-- --000000000000b5f91a05eee244b4 Content-Type: application/octet-stream; name=patch-08-use-or-assignments-to-set-noerrexit-bits Content-Disposition: attachment; filename=patch-08-use-or-assignments-to-set-noerrexit-bits Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lb783tw20 ZGlmZiAtLWdpdCBhL1NyYy9leGVjLmMgYi9TcmMvZXhlYy5jCmluZGV4IDFkZDU2OTAxOS4uMTgx MGZjYTVlIDEwMDY0NAotLS0gYS9TcmMvZXhlYy5jCisrKyBiL1NyYy9leGVjLmMKQEAgLTE0MTUs NyArMTQxNSw3IEBAIGV4ZWNsaXN0KEVzdGF0ZSBzdGF0ZSwgaW50IGRvbnRfY2hhbmdlX2pvYiwg aW50IGV4aXRpbmcpCiAJICAgIGludCBvZXJyZXhpdF9vcHQgPSBvcHRzW0VSUkVYSVRdOwogCSAg ICBQYXJhbSBwbTsKIAkgICAgb3B0c1tFUlJFWElUXSA9IDA7Ci0JICAgIG5vZXJyZXhpdCA9IE5P RVJSRVhJVF9FWElUIHwgTk9FUlJFWElUX1JFVFVSTjsKKwkgICAgbm9lcnJleGl0IHw9IE5PRVJS RVhJVF9FWElUIHwgTk9FUlJFWElUX1JFVFVSTjsKIAkgICAgaWYgKGx0eXBlICYgWl9TSU1QTEUp IC8qIHNraXAgdGhlIGxpbmUgbnVtYmVyICovCiAJCXBjMisrOwogCSAgICBwbSA9IGFzc2lnbnNw YXJhbSgiWlNIX0RFQlVHX0NNRCIsCkBAIC0xNDcyLDcgKzE0NzIsNyBAQCBleGVjbGlzdChFc3Rh dGUgc3RhdGUsIGludCBkb250X2NoYW5nZV9qb2IsIGludCBleGl0aW5nKQogCSAgICBuZXh0ID0g c3RhdGUtPnBjICsgV0NfU1VCTElTVF9TS0lQKGNvZGUpOwogCSAgICAvKiBzdXBwcmVzcyBlcnJl eGl0IGZvciBjb21tYW5kcyBiZWZvcmUgJiYgYW5kIHx8IGFuZCBhZnRlciAhICovCiAJICAgIGlm IChpc2FuZG9yIHx8IGlzbm90KQotCQlub2VycmV4aXQgPSBOT0VSUkVYSVRfRVhJVCB8IE5PRVJS RVhJVF9SRVRVUk47CisJCW5vZXJyZXhpdCB8PSBOT0VSUkVYSVRfRVhJVCB8IE5PRVJSRVhJVF9S RVRVUk47CiAJICAgIHN3aXRjaCAoV0NfU1VCTElTVF9UWVBFKGNvZGUpKSB7CiAJICAgIGNhc2Ug V0NfU1VCTElTVF9FTkQ6CiAJCS8qIEVuZCBvZiBzdWJsaXN0OyBqdXN0IGV4ZWN1dGUsIGlnbm9y aW5nIHN0YXR1cy4gKi8KQEAgLTE1NjgsNyArMTU2OCw3IEBAIHN1Ymxpc3RfZG9uZToKIAkgICAg ICovCiAJICAgIGludCBvZXJyZXhpdF9vcHQgPSBvcHRzW0VSUkVYSVRdOwogCSAgICBvcHRzW0VS UkVYSVRdID0gMDsKLQkgICAgbm9lcnJleGl0ID0gTk9FUlJFWElUX0VYSVQgfCBOT0VSUkVYSVRf UkVUVVJOOworCSAgICBub2VycmV4aXQgfD0gTk9FUlJFWElUX0VYSVQgfCBOT0VSUkVYSVRfUkVU VVJOOwogCSAgICBleGl0aW5nID0gZG9uZXRyYXA7CiAJICAgIHJldCA9IGxhc3R2YWw7CiAJICAg IGRvdHJhcChTSUdERUJVRyk7CmRpZmYgLS1naXQgYS9TcmMvbG9vcC5jIGIvU3JjL2xvb3AuYwpp bmRleCA2MTU0M2VkNzMuLjg4YzU1ZGQxYSAxMDA2NDQKLS0tIGEvU3JjL2xvb3AuYworKysgYi9T cmMvbG9vcC5jCkBAIC00MjgsNyArNDI4LDcgQEAgZXhlY3doaWxlKEVzdGF0ZSBzdGF0ZSwgVU5V U0VEKGludCBkb19leGVjKSkKICAgICB9IGVsc2UgewogICAgICAgICBmb3IgKDs7KSB7CiAgICAg ICAgICAgICBzdGF0ZS0+cGMgPSBsb29wOwotICAgICAgICAgICAgbm9lcnJleGl0ID0gTk9FUlJF WElUX0VYSVQgfCBOT0VSUkVYSVRfUkVUVVJOOworICAgICAgICAgICAgbm9lcnJleGl0IHw9IE5P RVJSRVhJVF9FWElUIHwgTk9FUlJFWElUX1JFVFVSTjsKIAogCSAgICAvKiBJbiBjYXNlIHRoZSB0 ZXN0IGNvbmRpdGlvbiBpcyBhIGZ1bmN0aW9uYWwgbm8tb3AsCiAJICAgICAqIG1ha2Ugc3VyZSBz aWduYWwgaGFuZGxlcnMgcmVjb2duaXplIF5DIHRvIGVuZCB0aGUgbG9vcC4gKi8K --000000000000b5f91a05eee244b4--