[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: $(( )): binary/unary VAR/NUM inconsistency

From: Chet Ramey
Subject: Re: $(( )): binary/unary VAR/NUM inconsistency
Date: Fri, 8 Jul 2022 12:08:38 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0

On 7/8/22 11:03 AM, Steffen Nurpmeso wrote:

Chet Ramey wrote in
  |On 7/7/22 12:11 PM, Steffen Nurpmeso wrote:
  |> Funnily my parser has only one (what i know) problem left, the
  |> same as bash.  On the other hand i found more.
  |The thing about all of this is that these are operators, and so delimit
  |tokens. Whitespace is siginficant only when determining the length of the
  |token or operator. Operators have context-dependent meaning (e.g., `+' can
  |be a unary or binary operator depending on context, and `++10' does not
  |mean the same thing as `+ +10').

Yes for one; but on the other hand all parsers _do_ resolve series
of (overly) successive operators, including bash.

Sure. Bash does a little more context analysis than it strictly should.

You quoted the "wrong" things again here, which i only included in
my message for context (i wholeheartly grant "my thoughts of
usable context", but then again you say it above, no?).

It's a tradeoff. If you want to look at more context, you're going to accept things that a strict parser would not. I did it because I had --
even in 2004 -- backwards compatibility to consider.

The problem of the bash parser is solely

   $ bash -c 'I=10;echo $((+10++I))'
   bash: line 1: +10++I: syntax error in expression (error token is "++I")

Again, it depends on how strict you want the parser to be. This is an error
in C, but not because it takes the ++ as a prefix increment operator. The
`++' is parsed as a post-increment operator incorrectly applied to an
integer constant.

This is why I said the bash arithmetic expression parser was forgiving: it
parses the operator as pre-increment if it's followed by something that
looks like an identifier.

whereas it does it right for numerics

   $ bash -c 'I=10;echo $((+10++10))'

This is where folks like kre are going to argue. It's not `right' according
to how a C compiler would parse that expression. But since it `works' if
you don't implement ++ and --, bash makes it work today.

I fixed that here today (if last "operator" is neither postfix nor
a number, and if the current operator is postfix, then check
whether a variable follows directly (after WS), if so, split
postfix into a binary to push, and decrement buffer by one; the
next is then parsed as UNARY and dropped, then we come to the

More or less.

  |> And one more thing.
  |>    -<802379605485813759>
  |>    +<9223372036854775807>
  |> This is from
  |>    $ bash -c 'echo $((999999999999999999999999999999999999999999999))'
  |>    802379605485813759
  |>    $ dash -c 'echo $((999999999999999999999999999999999999999999999))'
  |>    9223372036854775807
  |dash is what happens when you clamp the value at INTMAX_MAX (LLONG_MAX)
  |because it overflows -- but don't say anything about it -- instead of just
  |doing the conversion without checking for overflow. Neither value is
  |`right', and even the predictability of INTMAX_MAX is useless.

Yes, what the standard "itoa" gives you.

A nit: itoa is historical, but not standard. It's not in ISO C or POSIX.
The standard function is strtol/strtoll/strtoimax.

So you seem to use your own itoa, and here is (another) bash bug.

Yeah, that's where stricter integer constant parsing would flag an error.
It's just an extension; bash handles everything POSIX says it should
handle. It might be worth catching that case, but, then again, nobody has
ever reported it before now.

I think the POSIX people were talking about this; Eric Blake?
In this hindsight bash should bail with syntax error due to 0x:

   $ bash -c 'I=10;echo $((+10++0x))'

``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]