r200980 - [analyzer] Just silence all warnings coming out of std::basic_string.

[David Blaikie]

On Mon, Feb 10, 2014 at 9:50 AM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Feb 9, 2014, at 0:08 , David Blaikie <dblaikie at gmail.com> wrote:
>
> [analyzer] Just silence all warnings coming out of std::basic_string.
>>
>
> This does seem like a rather rough heuristic - is there nothing better?
> (more general - everything in the STL? What about every other string class
> everyone and their monkey have written? And I assume this isn't about
> strings, as such, but just a complexity problem with complex types and
> string just happens to be a commonly used one?)
>
>
> I know...these are all arguments I've made to Anna in resisting these
> sorts of changes, and now I'm the one making them.
>
> The particular problem with basic_string is in the short string / long
> string implementation; we've had repeated cases where the analyzer thinks
> there's a delete of stack memory or use-after-free. If we put more effort
> into union support (quite a bit, most likely), it would help a lot. (We may
> need better bitwise support as well.)
>

Could you use the presence of a union as the signal to suppress the
analyzer instead of specifically basic_string?


> It's possible a better heuristic would be to squelch warnings coming from
> classes that looks like containers, but that doesn't help if you're
> *implementing* a container class.
>

I assume other containers, like std::vector (which cannot have a
small-vector optimization), aren't actually a problem though, are they?


> But yes, this is an unfortunately reactionary change. I'm not happy with
> it either, but it seems better than false positives, and std::string
> variants have accounted for quite a few of the reported bugs in the
> analyzer's C++ support.
>

Agreed, better than false positives, but possibly worse than a more
general-purpose suppression based on the analyzer's weakness rather than
based on one instance of that weakness.

(don't mean to berate you for it - I get that you get where I'm coming from
- thanks!)

- David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140210/0d86ad6b/attachment.html>