[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:
Hello.
Chet Ramey wrote in
<9b6dfdc2-ade9-16ad-8960-5b2887b3533c@case.edu>:
|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))'
20
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
var).
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))'
10
Chet
--
``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/
- $(( )): binary/unary VAR/NUM inconsistency, Steffen Nurpmeso, 2022/07/06
- Re: $(( )): binary/unary VAR/NUM inconsistency, Andreas Schwab, 2022/07/06
- Re: $(( )): binary/unary VAR/NUM inconsistency, Chet Ramey, 2022/07/07
- Re: $(( )): binary/unary VAR/NUM inconsistency, Steffen Nurpmeso, 2022/07/07
- Re: $(( )): binary/unary VAR/NUM inconsistency, Chet Ramey, 2022/07/08
- Re: $(( )): binary/unary VAR/NUM inconsistency, Steffen Nurpmeso, 2022/07/08
- Re: $(( )): binary/unary VAR/NUM inconsistency, Steffen Nurpmeso, 2022/07/08
- Re: $(( )): binary/unary VAR/NUM inconsistency,
Chet Ramey <=
- Re: $(( )): binary/unary VAR/NUM inconsistency, Martin D Kealey, 2022/07/08
- Re: $(( )): binary/unary VAR/NUM inconsistency, Steffen Nurpmeso, 2022/07/09
- Re: $(( )): binary/unary VAR/NUM inconsistency, Robert Elz, 2022/07/08
- Re: $(( )): binary/unary VAR/NUM inconsistency, Chet Ramey, 2022/07/09