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.Dismiss alert
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).
I brought this up at 2023-04-19 GobCon, where the notes say:
This seems to be done here:
cil/src/frontc/cabs2cil.ml
Lines 5003 to 5008 in d2760ba
The text was updated successfully, but these errors were encountered: