<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Alexey!<br>
      <br>
      Could you share your ideas of checker design? It is possible that
      problems you met can be solved in different (maybe even better)
      way if we know the whole picture.<br>
      Regarding your questions, you can find some answers below.<br>
      <br>
      1. a) The first way for checker communication is to share their
      program state trait. You can see an example of how state trait is
      exported in GenericTaintChecker or MPIChecker. Generally, you just
      create a named ProgramStateTrait in the header. You can take a
      look at TaintManager.h and MPITypes.h and how they are used.<br>
      b) To set a dependency from another checker, you can just register
      it while registering your checker. An example can be found in
      MallocChecker where register$Checker also calls
      registerCStringCheckerBasic to register a checker it depends on.<br>
      As you pointed, inter-checker communication can become a source of
      some problems. Most of them are discussed in this conversation:
<a class="moz-txt-link-freetext" href="http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html">http://clang-developers.42468.n3.nabble.com/analyzer-RFC-Design-idea-separate-modelling-from-checking-td4059122.html</a><br>
      <br>
      2. I think there is nothing bad in sharing RegionState across
      checkers in the way shown in 1a.<br>
      <br>
      3. Artem Dergachev has done some excellent work on improvement of
      operator 'new' processing in CSA engine. Regarding checkers, I can
      see some on
      <a class="moz-txt-link-freetext" href="https://clang-analyzer.llvm.org/potential_checkers.html">https://clang-analyzer.llvm.org/potential_checkers.html</a>: for
      example, <span class="name">undefbehavior.AutoptrsOwnSameObj</span><span
        class="lang">. You can search this list to find more.</span><br>
      <br>
      <br>
      15.03.2018 23:54, Alexey Knyshev via cfe-dev пишет:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAM5izQu610rC9=M8xaP+no8_MwbWM0yY3ypavcNjH7eYddVJ0w@mail.gmail.com">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>
                <div>Hi there!<br>
                  <br>
                </div>
                While thinking about how it would be possible to
                implement various smart ptr related checkers I tried to
                review current state of MallocChecker and came up with
                that it would be great to have RegionState info
                available to other checkers. Could you please share your
                points of view and comments on the following statements
                / questions:<br>
                <br>
              </div>
              1. Is there any right way for chaining checkers? How they
              are expected to communicate between each other (excluding
              generation of nodes / ProgramStates). I've heard that
              there are couple of problems caused by inlining functions,
              constructors / descructors.<br>
            </div>
            2. What do you think about moving RegionState to the Core of
            CSA or providing optional extended info in MemRegion about
            the source of such region (new opearator / array new,
            malloc, alloca, etc). So it would be available to all
            checkers.<br>
          </div>
          3. Is there any roadmap for CSA and especially for dynamic
          memory management modeling & related checkers?<br>
          <br>
        </div>
        Regards, Alexey K<br clear="all">
        <div>
          <div>
            <div>
              <div>
                <div>
                  <div>
                    <div>
                      <div>
                        <div><br>
                          -- <br>
                          <div class="gmail_signature"
                            data-smartmail="gmail_signature">
                            <div dir="ltr"><a
href="https://www.linkedin.com/profile/view?id=AAMAABn6oKQBDhBteiQnWsYm-S9yxT7wQkfWhSw"
                                target="_blank" moz-do-not-send="true">linkedin.com/profile</a><br>
                              <br>
                              <a href="http://github.com/alexeyknyshev"
                                target="_blank" moz-do-not-send="true">github.com/alexeyknyshev</a><span></span><span></span><br>
                              <a
                                href="https://bitbucket.org/alexeyknyshev/"
                                target="_blank" moz-do-not-send="true">bitbucket.org/alexeyknyshev</a><br>
                            </div>
                          </div>
                        </div>
                      </div>
                    </div>
                  </div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
cfe-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <p><br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Best regards,
Aleksei Sidorin,
SRR, Samsung Electronics
</pre>
  </body>
</html>