zsh-workers
 help / color / mirror / code / Atom feed
From: Oliver Kiddle <opk@zsh.org>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: sh emulation POSIX non-conformances ("inf"/"Inf" in arithmetic expressions)
Date: Sat, 24 Apr 2021 00:46:44 +0200	[thread overview]
Message-ID: <55222-1619218004.791735@3FXq.NU49.vlrg> (raw)
In-Reply-To: <CAH+w=7ZMWJjB_tnGHW7kvkMr8MO4QQXuobjRMQeyxmTcK4fbyw@mail.gmail.com>

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.

> 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


  reply	other threads:[~2021-04-23 22:47 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 [this message]
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
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=55222-1619218004.791735@3FXq.NU49.vlrg \
    --to=opk@zsh.org \
    --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).