martong added a comment.

Thanks for the review guys.

Artem, I agree, that we should remove `LocAsInteger`. `LocaAsInteger` is a 
primitive handling of a specific cast operation (when we cast a pointer to an 
integer). The integration of  `LocaAsInteger` into the `SymExpr` hierarchy is 
problematic as both this patch and its parent shows.

For precision, we should produce a `SymbolCast` when we evaluate a cast 
operation of a pointer to an integral type. I agree with Denys, that 
`makeSymExprValNN` is probably not the best place to do that. I took Denys' 
patch D105340 <https://reviews.llvm.org/D105340> and created a prototype on top 
of that to create the `SymbolCast` in 
`SValBuilder::evalCastSubKind(loc::MemRegionVal V,`.

  void test_param(int *p) {
    long p_as_integer = (long)p;
    clang_analyzer_dump(p);            // 
expected-warning{{&SymRegion{reg_$0<int * p>}}}
    clang_analyzer_dump(p_as_integer); // expected-warning{{(long) (reg_$0<int 
* p>)}}

I'd like to upload that soon.

Once we produce the `SymbolCast`s, then we can start handling them 
semantically. In my opinion, we should follow these steps:

1. Produce `SymbolCast`s. This is done in D105340 
<https://reviews.llvm.org/D105340>, plus I am going to create another patch for 
pointer-to-int casts.
2. Handle `SymbolCast`s for the simplest cases. E.g. when we cast a (64bit 
width) pointer to a (64bit width unsigned) integer. This requires the 
foundation for an additional mapping in the `ProgramState` that can map a base 
symbol to cast symbols. This would be used in the constraint manager and this 
mapping must be super efficient.
3. Gradually handle more complex `SymbolCast` semantics. E.g. a widening cast.
4. Remove `LocAsInteger`. Produce the `SymbolCast`s by default and remove the 
option of `ShouldSupportSymbolicIntegerCasts`.

Point 2) and 3) are already started in D103096 
<https://reviews.llvm.org/D103096>. But again, I think first we have to get the 
solid foundations with the `State` and with the `ConstraintManager` before 
getting into the more complex implementations of widening.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D115932/new/

https://reviews.llvm.org/D115932

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to