[cfe-dev] [analyzer] Modeling a function with an out parameter pointer in check::PostCall

[via cfe-dev]

On Wed, Jun 24, 2020 at 1:58 AM Artem Dergachev <noqnoqneo at gmail.com> wrote:

>
> On 6/23/20 8:15 AM, philip.chimento at gmail.com wrote:
>
> On Sun, Jun 21, 2020 at 2:03 AM Artem Dergachev <noqnoqneo at gmail.com>
> wrote:
>
>>
>>
>> On 6/16/20 3:56 AM, philip.chimento at gmail.com wrote:
>>
>> On Sun, Jun 14, 2020 at 2:05 AM Artem Dergachev <noqnoqneo at gmail.com>
>> wrote:
>>
>>> > How do I get the SVal for the memory pointed to by
>>> CallEvent::getArgSVal(0)?
>>>
>>> ProgramState::getSVal (the overload that accepts the location/region).
>>>
>>
>> Thanks, that was it. I would never have thought that SVal ->
>> SVal::getAsRegion() -> ProgramState::getSVal() would have ended up with
>> anything but the original SVal, but there it is!
>>
>> Generally i recommend checking out a few links at the bottom of
>>> http://clang-analyzer.llvm.org/checker_dev_manual.html
>>>
>>
>> Speaking of that... would you be interested in merging my PR
>> https://github.com/haoNoQ/clang-analyzer-guide/pull/5 and some of the
>> other open PRs on the handbook, and releasing a new version? Depending on
>> how much of a hassle it is, I might be interested to make it publish as
>> HTML to GitHub Pages automatically so you wouldn't have to release PDFs...
>>
>>
>> Ugh, there are countless more outdated paragraphs in there. There are
>> even bugs documented that had to be fixed rather than documented. I emitted
>> it as an artifact that would have been created anyway at some point but i'm
>> personally not planning to maintain it further because it's not the right
>> way to do documentation (we'd rather have doxygen / rst documentation).
>> Please feel free to fork but i'd much rather have it converted to into
>> in-tree documentation (say, documentation in chapter 5 could be torn into
>> individual doxygen comments).
>>
>
> I can't honestly say that in-tree documentation would be more useful for
> people like me trying to develop checker plugins against a released version
> of clang... is there a middle ground where it could live in-tree but get
> rendered into something else than doxygen? The doxygen pages are super slow
> to load (especially if you accidentally load a large one) and difficult to
> search (nearly impossible if you don't already know what you're looking
> for).
>
>
> Mmm, strange. As a person who regularly googles class names in llvm.org
> doxygen, i've never had these problems. Say,
> https://clang.llvm.org/doxygen/classclang_1_1Decl.html loads instantly
> for me. I don't know how could that be slow aside from llvm.org servers
> suddenly being slow or a poor internet connection. Those are plain old
> static pages. Of course you have to know the class name in advance; doxygen
> is not great for tutorials. You can also always build doxygen locally and
> grep it (but that's not necessarily better than reading source code).
>

I took a look at this, it's less bad than I remembered, but the
slow-to-load ones have always been
https://llvm.org/doxygen/namespacellvm.html and
https://clang.llvm.org/doxygen/namespaceclang.html because they are so
large. I'm thinking maybe I confused "slow to load" with "difficult to find
the information I need" :-)
Cheers,
-- 
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200627/09d6a6ab/attachment-0001.html>