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,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22082 invoked from network); 23 Apr 2021 22:47:04 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 23 Apr 2021 22:47:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Message-ID:Date:Content-ID: Content-Type:MIME-Version:Subject:To:References:From:In-reply-to:Reply-To:Cc: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=YT/BqoxQ5TVDwj9QWK8jli4weuOW0fB5KQhqv9vW3DY=; b=Us/CauTB+Nr1HE62K2O4Jia3p+ zR9RJChOetwOIN+IqyzMOwrjVE9k6XsIbXSKoG5/l18vbUi7kmaOsS0pLmlURkbzCGS2Ww+HJ149u fDwxvuKwrfb2Ml7jQ0sjcZbJFLwAJeCNiWI4ZHV9Scltmf9ZyzGjEFVNwZb+rZFe0sLMJ03WVdfvJ LnJzmfklUcYFQNOy+BJBLSfwVnVd9WLaDJrHOMSZjBwU4Pqc38hmmdgcPJB/pbAixVCVCEquwTyVh c6kJdmj1689Cy2HaAkVP4e+OwTlVTjacr4wwvfXgiuRCx994j/3+7c4fyTEmcAwLkwZb5SGwS5UCF uPZl6KVA==; Received: from authenticated user by zero.zsh.org with local id 1la4Zi-000Jvw-2B; Fri, 23 Apr 2021 22:47:02 +0000 Received: from authenticated user by zero.zsh.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256) id 1la4ZT-000Ji3-Ok; Fri, 23 Apr 2021 22:46:48 +0000 Received: from [192.168.178.21] (helo=hydra) by mail.kiddle.eu with esmtp(Exim 4.94) (envelope-from ) id 1la4ZQ-000EMh-Pd for zsh-workers@zsh.org; Sat, 24 Apr 2021 00:46:46 +0200 In-reply-to: From: Oliver Kiddle References: <7FD930F4-37CD-402B-9A06-893818856199@dana.is> <20210411175726.hxnm33mxoska2tsm@chazelas.org> <20210411193154.zkekzvb4o6xmriwo@chazelas.org> <20210413071742.tisslgg5fdqbageg@chazelas.org> <20210422153100.GD154089@zira.vinc17.org> <20210423164525.GA2033191@zira.vinc17.org> To: Zsh hackers list Subject: Re: sh emulation POSIX non-conformances ("inf"/"Inf" in arithmetic expressions) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <55221.1619218004.1@hydra> Date: Sat, 24 Apr 2021 00:46:44 +0200 Message-ID: <55222-1619218004.791735@3FXq.NU49.vlrg> X-Seq: 48681 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: Bart Schaefer wrote: > On Fri, Apr 23, 2021 at 9:46 AM Vincent Lefevre wrote: > > > > IMHO, zsh should also output a warning when such variables are used. I disagree. We also have variables named 0, 1, 2, 3 and so on - the positional parameters. But nobody would suggest warning about literal value 7 in maths context. > So, it's the "expend effort on a check that is nearly always going to > fail" option. I can just about see the case for warning on typeset -i/-F inf or nan but not on use. The traditional Unix approach is not to stop people who choose to shoot themselves in the foot. In a maths expression, you're going to end up with inf, -inf or nan as your result anyway so it quickly becomes fairly obvious what is going on. If we're worrying about POSIX compliance, it'd be easy enough to disable Inf and NaN in POSIX mode but there are dozens of special variables defined that aren't in the POSIX spec either and which could clash. While @inf would have avoided clashing with the variable, I've not seen any other language which does that and consistency makes it easier. The shell is one language where special characters should be especially avoided because it is used interactively. Not everyone has a US-layout keyboard and @ is often in weird places. It'd also raise the question of what we should output. printf should follow the standard. Note that in bash (and quite a few other implementations): printf '%f\n' inf inf It is generally helpful to be able to re-input the output as input in a later line of code. > + if (issetvar(p)) { > + zwarn("%s: using constant NaN", p); I'm not sure that "constant" is even the correct term for what NaN or even Inf is? Note that NaN == NaN is, by definition, false. For an accurate description perhaps check IEEE754 but it is more along the lines of being an intrinsic literal value. > integer Inf > print $(( Inf[0] )) > 1:Refer to Inf with an array subscript That could potentially be made to work as an array lookup because subscripts have no other meaning that would clash. Oliver