You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.
Although -9223372036854775808 is the minimum integer that int64 can express, BQL cannot parse it correctly. That is because it tries to parse the number as an unsigned int64 value rather than a negative int value.
You are right, when parsing an expression, the parser checks the various expressions defined in bql.peg: is it an orExpr, is it an andExpr, ..., is it a minusExpr, 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 only 9223372036854775808 and this is too large, as you wrote.
As a side note: Our definition of NumericLiteral includes an optional - character, so
EVAL - -9223372036854775808;
is parsed as a minusExpr of the negative number -9223372036854775808 correctly. However, when the minus before is applied, we get 9223372036854775808 which overflows int64 and becomes -9223372036854775808 again.
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:
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: