<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 10, 2014 at 9:50 AM, Jordan Rose <span dir="ltr"><<a href="mailto:jordan_rose@apple.com" target="_blank">jordan_rose@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div class=""><br><div><div>On Feb 9, 2014, at 0:08 , David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><blockquote class="gmail_quote" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
[analyzer] Just silence all warnings coming out of std::basic_string.<br></blockquote><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
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?) </div>
</blockquote></div><div><br></div></div><div>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.</div><div><br></div><div>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.)</div>
</div></blockquote><div><br></div><div>Could you use the presence of a union as the signal to suppress the analyzer instead of specifically basic_string? </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div>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 <i>implementing</i> a container class.<br>
</div></div></blockquote><div><br></div><div>I assume other containers, like std::vector (which cannot have a small-vector optimization), aren't actually a problem though, are they?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div></div><div>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.</div>
</div></blockquote><div><br>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.<br><br>(don't mean to berate you for it - I get that you get where I'm coming from - thanks!)<br>
<br>- David </div></div></div></div>