<div dir="ltr">Ah, I see. Though, in the specific case of MallocChecker, I wonder whether there's any point of using it once we touch postCall anyways.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 Feb 2020 at 15:53, Artem Dergachev <<a href="mailto:noqnoqneo@gmail.com">noqnoqneo@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 2/26/20 6:45 PM, Artem Dergachev wrote:<br>
> Yes, we should remove the old code for c++-allocator-inlining=false. <br>
> The worry we've had back then was that in the new mode we've disabled <br>
> aggressive behavior of MallocChecker in which it reacted to some <br>
> overloaded operator new invocations but i think this was the right <br>
> thing to do and also nobody complained; also nothing prevents us from <br>
> bringing back the old behavior in a much less confusing way.<br>
><br>
> Using a CXXAllocatorCall sounds wonderful as well. I'm afraid it might <br>
> be technically difficult to do so because our Environment is screwed <br>
> due to CXXNewExpr serving two different purposes, so there's a wrong <br>
> SVal attached to it and CallEvent might be unable to retrieve the <br>
> right SVal, so we're passing it separately. If this issue is solved, <br>
> we might as well provide these callbacks as part of <br>
> checkPreCall/checkPostCall and then abandon the check::NewAllocator <br>
> callback entirely. More discussion on this in <br>
> <a href="http://lists.llvm.org/pipermail/cfe-dev/2017-December/056314.html" rel="noreferrer" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2017-December/056314.html</a><br>
><br>
> I think at this point we might actually do a good job sorting out this <br>
> check::NewAllocator issue because we have a "separate" "Environment" <br>
> to hold the other SVal, which is "objects under construction"! - so we <br>
> should probably simply teach CXXAllocatorCall to extract the value <br>
> from the objects-under-construction trait of the program state and <br>
> we're good.<br>
<br>
Nvm, i'm wrong. CXXAllocatorCall should have the value before the cast <br>
but "objects under construction" and check::NewAllocator should have the <br>
value after the cast. So there's still no easy way to fix CXXAllocatorCall.<br>
<br>
><br>
> On 2/26/20 5:02 PM, Kristóf Umann via cfe-dev wrote:<br>
>> Hey!<br>
>><br>
>> This is short and sweet. MallocChecker uses both check::newAllocator <br>
>> and check::postStmt<CXXNewExpr> to model aspects of operator new. <br>
>> Mind that these two are redundant not only with each other, but with <br>
>> the already used check::postCall. The reason I can see is handling <br>
>> all values of the analyzer config c++-allocator-inlining.<br>
>><br>
>> So, this flag has been true by default for a long-long time, and I <br>
>> personally never changed had the need to change it. Is there a need <br>
>> to keep tiptoeing around it? Here is a patch that tackles the issue, <br>
>> but it quite dated and I'm not too sure about the current state of <br>
>> things.<br>
>><br>
>> [analyzer] Add a new checker callback, check::NewAllocator.<br>
>> <a href="https://reviews.llvm.org/D41406" rel="noreferrer" target="_blank">https://reviews.llvm.org/D41406</a><br>
>><br>
>> Also, shouldn't we make check::NewAllocator provide a <br>
>> CXXAllocatorCall rather then a CXXNewExpr and a related <br>
>> under-construction SVal?<br>
>><br>
>> Cheers,<br>
>> Husi<br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</blockquote></div>