Parsing -9223372036854775808 fails #56
Open
Comments
I added a note to the documentation about this bug (in |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report by @nobu-k:
You are right, when parsing an expression, the parser checks the various expressions defined in
bql.peg
: is it anorExpr
, is it anandExpr
, ..., is it aminusExpr
, and in fact if there is a-
character discovered, it will be pushed on the stack and the remainder will be processed separately. Therefore the parser sees only9223372036854775808
and this is too large, as you wrote.I think the only possibility to fix this is to modify/extend the definition of
minusExpr
so that the minus is not split off if it is followed by a number or so. However, we need to be careful in order with respect to operator precedence, I think. At the moment,-1.5::int
is understood as-(1.5::int)
and we should either (a) make sure it stays that way or (b) prove that it doesn't ever make a difference for int/float conversion whether we do-(1.5::int)
or(-1.5)::int
.The text was updated successfully, but these errors were encountered: