NoQ added inline comments.

================
Comment at: clang/lib/StaticAnalyzer/Checkers/FuchsiaHandleChecker.cpp:19-20
+// handle variable is passed to different function calls or syscalls, its state
+// changes. The state changes can be generally represented by following ASCII
+// Art:
+//
----------------
Btw, this state machine is fairly common. Both MallocChecker and 
SimpleStreamChecker already follow this same model. Do you have any thoughts on 
re-using it in an abstract manner?

Something like this maybe?:
```lang=c++
template <typename TraitID>
class SimpleStreamStateMachine {
public:
  SimpleStreamStateMachine(void(*pointerEscapePolicy)(CheckerContext C, Other 
Customizations));

  ProgramStateRef makeOpened(ProgramStateRef State, SymbolRef Key) {
    return State->set<TraitID>(Key, TraitID::ValueTy::makeOpened());
  }
  // makeReleased and so on pre-defined for all users,
  // allowing customization when necessary.
};

class SimpleStreamStateMachineBookkeeping : Checker {
public:
  checkDeadSymbols() {
    // Perform the state cleanup for all concrete machines
    // ever instantiated, in the only possible way, probably
    // invoke callbacks for leaks.
  }
  checkPointerEscape() {
    // Invoke the passed-down policy for each concrete
    // state machine.
  }
  // Other callbacks are implemented in the dependent checker.
};
```
And then:
```lang=c++
REGISTER_MAP_WITH_PROGRAMSTATE(MyTrait, SymbolRef, MyState);

class MyChecker : Checker {
  SimpleStreamStateMachine<MyStateTy> StM {
      getStateMachine<SimpleStreamStateMachine<MyStateTy>>(
          &MyChecker::checkPointerEscapeImpl, /*Other Customizations*/)};
  void checkPointerEscapeImpl(...);

public:
  checkPostCall(...) {
    C.addTransition(StM.makeOpened(C.getState(), Call.getRetVal()));
  }
};
```

'Cause i have this pipe dream that we make a lot of such abstract state 
machines and then we'll never need to write more of them and that'll make it 
cheaper to introduce non-trivial operations over the program state such as 
replacing values or advanced widening because we'll only have to implement them 
in the few state machines rather than in many checkers.


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

https://reviews.llvm.org/D70470



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

Reply via email to