On Mon, Feb 10, 2014 at 9:50 AM, Jordan Rose <[email protected]> wrote:
> > On Feb 9, 2014, at 0:08 , David Blaikie <[email protected]> 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
