forked from cil-project/cil
-
Notifications
You must be signed in to change notification settings - Fork 24
Open
Labels
Description
I brought this up at 2023-04-19 GobCon, where the notes say:
Why does CIL insert annoying integer casts to all pointer equality checks?
- E.g.
((unsigned long)x) == ((unsigned long)y)- This is in particular an issue as the int-type they are cast-to depends on the architecture. Therefore, combining on a different architecture changes the results!
- Possible issue with casts being inserted before CIL merging; and types changing after the CIL merge
- The standard demands no such thing?
- C11 6.5.9.2: “One of the following shall hold: [...] - both operands are pointers to qualified or unqualified versions of compatible types;”
- C11 6.5.9.4: “If both of the operands have arithmetic type, the usual arithmetic conversions are performed.”
- Proposition: Double check that these casts are not needed, then do not insert them in
- Check whether pointers of different type can be compared without a cast according to the C standard
- If not, then check whether attributes (which may be collected during merging) are relevant with regard to (f).
- If attributes are not relevant or if pointers of different type can be compared, then we can remove the casts (at least for pointers of the same type).
This seems to be done here:
Lines 5003 to 5008 in d2760ba
| let pointerComparison e1 t1 e2 t2 = | |
| (* Cast both sides to an integer *) | |
| let commontype = !upointType in | |
| intType, | |
| optConstFoldBinOp false bop (makeCastT ~e:e1 ~oldt:t1 ~newt:commontype) | |
| (makeCastT ~e:e2 ~oldt:t2 ~newt:commontype) intType |
Reactions are currently unavailable