forked from cil-project/cil
-
Notifications
You must be signed in to change notification settings - Fork 22
Open
Labels
Description
Formatcil can parse the following expression (from Goblint's Apron analysis): 2147483647LL - (long long )top >= 0.
When Goblint evaluates the parsed expression, it crashes with:
exception IntDomain.IncompatibleIKinds("ikinds long long and int are incompatible. Values: (Unknown int([0,32])) and (0)")
Turns out Formatcil doesn't insert implicit casts on both sides of the comparison to make the types same:
Lines 87 to 92 in 56f5f9a
| let doBinop bop e1t e2t = | |
| ((fun args -> | |
| let e1 = (fst e1t) args in | |
| let e2 = (fst e2t) args in | |
| let t1 = typeOf e1 in | |
| BinOp(bop, e1, e2, t1)), |
Even worse, it uses the type of the left argument as the type of any binary operator expression, which is also blatantly incorrect.
Meanwhile Frontc does the appropriate conversion to deduce the result type and inserts the necessary casts:
Lines 4915 to 4920 in 56f5f9a
| let doArithmeticComp () = | |
| let tres = arithmeticConversion t1 t2 in | |
| (* Keep the operator since it is arithmetic *) | |
| intType, | |
| optConstFoldBinOp false bop | |
| (makeCastT ~e:e1 ~oldt:t1 ~newt:tres) (makeCastT ~e:e2 ~oldt:t2 ~newt:tres) intType |
It's starting to look more and more unlikely that we can keep abusing Formatcil to parse individual expressions.