zsh-workers
 help / color / mirror / code / Atom feed
From: Vincent Lefevre <vincent@vinc17.net>
To: zsh-workers@zsh.org
Subject: Re: sh emulation POSIX non-conformances ("inf"/"Inf" in arithmetic expressions)
Date: Sun, 25 Apr 2021 01:02:19 +0200	[thread overview]
Message-ID: <20210424230219.GD2587578@zira.vinc17.org> (raw)
In-Reply-To: <55222-1619218004.791735@3FXq.NU49.vlrg>

On 2021-04-24 00:46:44 +0200, Oliver Kiddle wrote:
> Bart Schaefer wrote:
> > On Fri, Apr 23, 2021 at 9:46 AM Vincent Lefevre <vincent@vinc17.net> 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.

This is different: the digits are already used in integers, and the
behavior is the same in all shells.

> > 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.

People could waste a lot of time finding what is going on,
in particular those who don't use floating point at all.

> 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.

However, it is a bit easier to see what is going on with special
variables. And they have been documented for a long time. On the
opposite, the zsh manual (for 5.8) is silent on Inf and NaN. And
both for the behavior and documentation, be careful with the
locales, in particular in Turkish ones. I don't know whether
this is expected in zsh, but...

zira% zsh -fc 'export LC_ALL=fr_FR.utf8; echo $((Inf)) $((inf))'
Inf Inf
zira% zsh -fc 'export LC_ALL=tr_TR.utf8; echo $((Inf)) $((inf))'
Inf 0

With ksh93:

zira% ksh93 -fc 'export LC_ALL=fr_FR.utf8; echo $((Inf)) $((inf))'
inf inf
zira% ksh93 -fc 'export LC_ALL=tr_TR.utf8; echo $((Inf)) $((inf))'
inf inf

> It is generally helpful to be able to re-input the output as input
> in a later line of code.

Even with the POSIX behavior, a problem is unlikely to occur,
because zsh uses a mix of uppercase and lowercase letters, and
this is uncommon in variable names. Moreover, if people get Inf
or NaN in their computation, I doubt that they would use such
variable names.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


  parent reply	other threads:[~2021-04-24 23:02 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-10 23:31 [PATCH] Document imperfections in POSIX/sh compatibility dana
2021-04-10 23:50 ` Bart Schaefer
2021-04-11  0:19   ` dana
2021-04-11 16:54     ` Bart Schaefer
2021-04-11 17:57       ` sh emulation POSIX non-conformances (Was: [PATCH] Document imperfections in POSIX/sh compatibility) Stephane Chazelas
2021-04-11 18:13         ` Bart Schaefer
2021-04-11 19:18         ` sh emulation POSIX non-conformances (no word splitting upon arithmetic expansion) Stephane Chazelas
2021-04-22 15:03           ` Vincent Lefevre
2021-04-22 18:27             ` Bart Schaefer
2021-04-11 19:31         ` sh emulation POSIX non-conformances ("inf"/"Inf" in arithmetic expressions) Stephane Chazelas
2021-04-12 20:41           ` Bart Schaefer
2021-04-13  7:17             ` Stephane Chazelas
2021-04-22 15:31               ` Vincent Lefevre
2021-04-22 18:55                 ` Bart Schaefer
2021-04-22 20:45                   ` Daniel Shahaf
2021-04-22 21:25                     ` Bart Schaefer
2021-04-23 16:45                   ` Vincent Lefevre
2021-04-23 20:31                     ` Bart Schaefer
2021-04-23 22:46                       ` Oliver Kiddle
2021-04-23 23:34                         ` Bart Schaefer
2021-04-24  2:10                           ` Daniel Shahaf
2021-04-24  3:42                             ` Bart Schaefer
2021-04-24  7:33                               ` Stephane Chazelas
2021-04-24 16:04                                 ` Bart Schaefer
2021-04-24 23:02                         ` Vincent Lefevre [this message]
2021-04-25  2:18                           ` Bart Schaefer
2021-04-25 20:17                             ` Vincent Lefevre
2021-04-25 21:58                               ` Bart Schaefer
2021-04-26 10:28                                 ` Vincent Lefevre
2021-04-25 22:00                               ` Bart Schaefer
2021-04-26 10:34                                 ` Vincent Lefevre
2021-04-26 23:25                                   ` Vincent Lefevre
2021-04-11 19:33         ` sh emulation POSIX non-conformances (some of zsh's special variables) Stephane Chazelas
2021-04-11 19:42         ` sh emulation POSIX non-conformances (printf %10s and bytes vs character) Stephane Chazelas
2021-04-13 15:57           ` Daniel Shahaf
2021-04-13 18:03             ` Stephane Chazelas
2021-04-13 21:09               ` Bart Schaefer
2021-04-22 13:59           ` Vincent Lefevre
2021-04-22 14:28             ` Vincent Lefevre
2021-04-22 19:22             ` Bart Schaefer
2021-04-23 16:53               ` Vincent Lefevre
2021-04-23 23:01                 ` Oliver Kiddle
2021-04-24 21:41                   ` Vincent Lefevre
2021-04-24 21:46                   ` Vincent Lefevre
2021-04-24  7:09                 ` Stephane Chazelas
2021-04-24 21:52                   ` Vincent Lefevre
2021-04-24 22:28                     ` Bart Schaefer
2021-04-24 23:18                       ` Vincent Lefevre
2021-04-25  2:20                         ` Bart Schaefer
2021-04-25 11:07                           ` Vincent Lefevre
2021-04-11 23:04       ` [PATCH] Document imperfections in POSIX/sh compatibility dana
2021-04-13 16:01 ` Daniel Shahaf
2021-04-13 16:12   ` Peter Stephenson
2021-04-13 20:28   ` Oliver Kiddle
2021-04-13 21:40     ` dana
2021-04-13 22:02       ` Bart Schaefer
2021-04-14 12:38       ` Daniel Shahaf
2021-04-18  4:50         ` dana
2021-04-20 21:26           ` Daniel Shahaf
2021-05-03 23:42             ` dana

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210424230219.GD2587578@zira.vinc17.org \
    --to=vincent@vinc17.net \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).