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 1961 invoked from network); 16 Nov 2022 06:32:56 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 16 Nov 2022 06:32:56 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20210803; t=1668580376; b=TD0CGdNWtS65nWWayrHLk87OgTu4tmqzQE40pS9FkWIDAihs1pGQ14fRxYiOYWDpbxNV/LqrJK suTeAURY2xQbL6dFlfmRiNXXWwgzltS83l0TpPqHh113h4WQQ09MsGkrl1X9bc3mDwbAOX6Hu8 JpwSTl9lxbII3yVHZqftJ8OSsRmm6uD3+1M9ZlBNU38BxleNr72bdVK3SXWViW+bxAVVPaiEmy BhH6oD1wlfP7JJRR7spJo0N+DrUyBWsN74V0C4DVhBYtCqZ9gIPLPTJGRpoVxnfaPRBuKTd8Jm guqJyq04fULIxck/YYHxfQIHlT9FQZBxXehTJHipNaPqrg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-ua1-f42.google.com) smtp.remote-ip=209.85.222.42; 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=1668580376; bh=e095Nt5ruDbK0YlOdkJbbpvYgae62c+iE1vvgyGNf9Q=; 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=XTN9ZfappCB1uNEcrWZyEbLvJN66PQ26s/zj6IlZBGtaEBSVyW5Vl9HNCHcN3Kp2qCYVyvOY13 v9L/1p1XqmCfg+jG/frRCLCeehqpmuPNa7CdhfFDV8ujBn+Pq8inveAfE+rfa2M4cC3nFywWhR X3lPpOntHdTE80UxfJ3BjGDIvlqsEjIVdsHnWRnItGgVf4FFEM3EdPNBMoGi9aIzUJXIvCW1X1 lLI7DMmvbBCArttc7YORNzahrOWCpamBtdw7oBd5XkMSHdMlgTtpdKY3V1uOhJ0RYO7Me78KnM clu0AyClLtmxTqRczMNFwtAcidi8nsAcDViVwUNcP4xg5A==; 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=U500tPfrPucSWlsOjcw0EYomNj4urmHezKoDSu1KKLQ=; b=gmJ3e+7hLEDqtEDR0rnakw6IZF LaY5P95HPtYL9LkVuSOe7Tav19gGRnqUfd66Fuvw4IPt3+DSgJLKeIvmFTLgUaJyPcYPkQILACSbt MPZfXA/jlo9WlKRTxx6+egMfANIZP3aUbZM3lbSzQ1OKF/sCI27xWWLH4f0yF7OSBP1qPQb+tekBr vwTEuv+LBNI+pLYBOMlBFGGbBu80JpmknSnPLItExB6eZfvTTgHCzm6ICw/nrmfbfnf6BScwibMKG jdyP5LTp7fnGepvcH1SWY6qbUGxH0EO7YI01Q34wkS2o5Zc9gHO3zA+aT+ptnhxVNOrtZ4l4mkd3m 9EVFG/Jg==; Received: by zero.zsh.org with local id 1ovByh-000Mp1-RO; Wed, 16 Nov 2022 06:32:55 +0000 Authentication-Results: zsh.org; iprev=pass (mail-ua1-f42.google.com) smtp.remote-ip=209.85.222.42; dkim=pass header.d=gmail.com header.s=20210112 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-ua1-f42.google.com ([209.85.222.42]:34775) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1ovBxt-000MTt-H2; Wed, 16 Nov 2022 06:32:05 +0000 Received: by mail-ua1-f42.google.com with SMTP id w2so3841419uap.1; Tue, 15 Nov 2022 22:32:05 -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=U500tPfrPucSWlsOjcw0EYomNj4urmHezKoDSu1KKLQ=; b=cojSBW7CS5cO4mHCDGs8TVEdVk7RVonSErwmTXEuYJDSYYq78pUzQEClhXtf8RWVz9 INcyWaIDRea0VSwpQMUDbQRZ8duRmiz5/bqrYY2uW4DYFpFRtkLKycJfUGFsqd0zAhCv l0/sIbn7RR2D1Ck1RWmcUDDtELAAyppdX8LYHNp5actmN8ljss3eWInmnetiKVGq1w0O TEfksmizeL5J26rVV5qxZsiggT5VuP07c/ClLfkiK5xdvytXyQ3L5+aTJxU8uHwnXy8x DV2yJY2F3OcD09E50Q/MzvqkAjSGtpraAYZSFF88C8laOgLybZx+z44raYdkR3ZpnFTG +IFA== 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=U500tPfrPucSWlsOjcw0EYomNj4urmHezKoDSu1KKLQ=; b=lmQN4keQLh+l48LjYNp+IQbOM++Xy5LJYj6XAPZsgue1JcN5J1f84KmAlUVsK4XaC2 UbRW0EM3GWX8by4A9GCu2fF52J8JbbKDx9K94wbQ5RN4znHY66RvPrJMOwWcUAWWrGWB Y2WFHp5SRrtHE42bl2A9VLFtLhjDk62jAqNtj0Rxp69JAcyOhl03EA+be6sKCp51ADXB UEYMfxblInRgYwKRqp00T8+7KG1iHBJA5cHxYkOPuBnezJ7FfGyJ/qj/p8BnA2P9OX4r f5WWfg8dA/19Mul+FxQ0d7XxFIf49OihjyjS3uKS4fAcQPbxf0x5XLgPfUzNpI6AXV0u QDBw== X-Gm-Message-State: ANoB5pm3/hVQ1XZ6Do2yJlLlswakHMiGHzslm4QEDbMMbu+5s1RggnL7 V3jfKpinr5Vf7dJ2Tp0XhEuhsUkMNZfKfaFqOBA6ZPOCl/g= X-Google-Smtp-Source: AA0mqf7yo5l4S0bwYC5IEap0vbJLM1f4qajpDSOGU+C12BIQqKG0KGgiCWVzzcILcENCgMIhVtmpB8d00xqjG+xehMc= X-Received: by 2002:ab0:39d6:0:b0:3dc:4480:777 with SMTP id g22-20020ab039d6000000b003dc44800777mr11746651uaw.104.1668580323883; Tue, 15 Nov 2022 22:32:03 -0800 (PST) MIME-Version: 1.0 References: <68e48647-7713-4b77-b719-d836d2671b06@app.fastmail.com> In-Reply-To: <68e48647-7713-4b77-b719-d836d2671b06@app.fastmail.com> From: Philippe Altherr Date: Wed, 16 Nov 2022 07:31:52 +0100 Message-ID: Subject: Re: [PATCH] More ERR_EXIT (was Re: Tests RE behavior of ERR_EXIT) To: =?UTF-8?Q?Lawrence_Vel=C3=A1zquez?= Cc: Bart Schaefer , zsh-workers@zsh.org Content-Type: multipart/alternative; boundary="0000000000007bff1b05ed90a115" X-Seq: 50977 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: --0000000000007bff1b05ed90a115 Content-Type: text/plain; charset="UTF-8" > > Here are two additional cases that your patch does not cover. They > are not regressions, as stable zsh 5.9 is also affected. Interesting! And the symptoms are exactly the same as they were with function calls: - If you replace "echo done" with "echo done $?" you can see that the "source" and "eval" statements return the right exit status. They "just" fail to trigger ERR_EXIT. - When you drop the "if" statement and only keep "false && true", then ERR_EXIT is correctly triggered. It looks like another case where saving and restoring this_noerrexit is missing. And, indeed, if save and restore this_noerrexit are added just before and after this execlist in execode, then your examples work and all tests still pass. The function execode is called from builtin.c in the eval function. In that context the saving and restoring looks warranted. But there are multiple other calls, mainly in exec.c. Although for most it looks right to save and restore, I can't say confidently that it's indeed the case for all of them. I also wonder whether other elements of the execution stack should be saved and restored. For function calls, there are many more things that are saved and restored. I also noticed that zsh.h declares a structure execstack , which is used in exec.c to implement execsave , which saves the state of the execution stack, and execrestore , which restores it. Surprisingly these two methods are only used once in signals.c (here and. here ). And even more surprisingly, even though plenty of variables are saved, including this_noerrexit, the variable noerrexit is NOT saved, which looks very suspicious to me. How should we proceed? I'm 99% sure that my current patch (without the changes mentioned above) is correct (i.e., it fixes a number of problems and doesn't introduce new ones). At the moment, I'm much less confident about changing execode as described above or about adding noerrexit to execstack. Would it make sense to submit my pacth (once I have fixed Changlelog and 1-2 other things) and try to solve the other problems in follow-up patches? Philippe --0000000000007bff1b05ed90a115 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are= two additional cases that your patch does not cover.=C2=A0 They
are not= regressions, as stable zsh 5.9 is also affected.

Interesting! And the symptoms are exactly th= e same as they were with function calls:

- If you=C2=A0r= eplace "echo done" with "echo done $?" you can see that= the "source" and "eval" statements return the right ex= it status. They "just" fail to trigger ERR_EXIT.
- When= you drop the "if" statement and only keep "false &&= true", then ERR_EXIT is correctly triggered.

It looks like another case where saving and restoring=C2=A0this_noerrexit = is missing. And, indeed, if save and restore this_noerrexit are added just = before and after this execlist in exec= ode, then your examples work and all tests still pass. The function=C2=A0execode=C2=A0is called from builtin.c in= the eval function. In that context= the saving and restoring looks warranted. But there are multiple other cal= ls, mainly in exec.c. Although for most it looks right to save and restore,= I can't say confidently that it's indeed the case for all of them.= I also wonder whether other elements of the execution stack should be save= d and restored. For function calls, there are many more things that are sav= ed and restored.

I also noticed that zsh.h declare= s a structure execstack, which is used = in exec.c to implement=C2=A0execsave, = which saves the state of the execution stack, and execrestore, which restores it. Surprisingly these two methods = are only used once in signals.c (here and. here). And even more surpri= singly, even though plenty of variables are saved, including this_noerrexit= , the variable noerrexit is NOT saved, which looks very suspicious=C2=A0to = me.

How should we proceed? I'm 99% sure that m= y current patch (without the changes mentioned above) is correct (i.e., it = fixes a number of problems and doesn't introduce new ones). At the mome= nt, I'm much less confident about changing execode as described above o= r about adding noerrexit to=C2=A0execstack. Would it make sense to submit m= y pacth (once I have fixed Changlelog=C2=A0and 1-2 other things) and try to= solve the other problems in follow-up patches?

Ph= ilippe

--0000000000007bff1b05ed90a115--