<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Jordan is right. We can’t just move these wholesale. We quite honestly don’t know who are using these options, but they are clearly exposed by scan-build.</div><div><br></div><div>If we want to move these, we’d need a notion of an “alias”. It quickly gets complicated, however.</div><div><br></div><div>Perhaps related, unlike clang diagnostics, we cannot have a check in multiple groups. I always saw this as a feature, as it simplified the model. That said, over time we’ve seen that checks don’t necessarily fall into any single group. If we had a cogent mechanism for putting checks in multiple groups that was easy to understand then remappings like this might be fairly straightforward.</div><div><br></div><div>In the meantime, I don’t think this renaming is worth it. That said, we should consider whether or not new checks should go into a new category.</div><br><div><div>On Mar 20, 2014, at 9:28 AM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Do you (either of you) think it's worth keeping compatibility names for checkers in 'unix' that move to 'generic'? I don't care so much about the checkers in 'core' because no one should be explicitly turning those on or off, but the Unix ones might be in use.</div><div><br></div><div>Jordan</div><div><br></div><br><div><div>On Mar 19, 2014, at 18:11 , Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I’d be fine with breaking ‘core’ into ‘core’ and ‘generic’, which clearly delineates between built-in functionality that is part of the analyzer basically doing its job and extensions to that behavior via the use of opt-in checkers.<div><br><div><div>On Mar 19, 2014, at 5:10 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>It depends if we want to move existing checkers around or not. If not, I'm not sure it's worth moving MismatchedDeallocators from where it is right now. The "unix" checkers are turned on on all platforms right now. If we do want to break "core" into "core" and "generic" then MismatchedDeallocators, along with Malloc itself, should be moved into "generic" (or whatever we decide to call it.)</div><div><br></div><div>My inclination is to leave it where it is right now.</div><div><br></div><div>(The reason to move it to cplusplus is to skip the check in C modes. That'd be correct right now but not in the future. We may or may not care.)</div><div><br></div><div>Jordan</div><div><br></div><br><div><div>On Mar 19, 2014, at 17:08, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">You didn’t really answer my question. What is the right answer here?<div><br><div><div>On Mar 19, 2014, at 2:05 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>"unix" includes an awful lot of generic things (like malloc itself). Part of the problem here is that our "core" checkers are always on. We don't have "generic-but-not-required" checkers right now.</div><div><br></div><div>Jordan</div><div><br></div><br><div><div>On Mar 19, 2014, at 13:55, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">By that argument, does it belong in “unix”? What about Windows-specific allocators?<div><br><div><div>On Mar 19, 2014, at 1:45 PM, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>It's <i>currently</i> specific to C++, but I'm not sure it's <i>inherently</i> specific to C++. I can imagine the FreeBSD guys adding support for custom C allocators too. So I'm not sure it's worth moving.</div><div><br></div><div>Jordan</div><div><br></div><br><div><div>On Mar 19, 2014, at 13:27, Ted Kremenek <<a href="mailto:kremenek@apple.com">kremenek@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Seems fine to me.<br><br>On Mar 19, 2014, at 1:12 PM, Anton Yartsev <<a href="mailto:anton.yartsev@gmail.com">anton.yartsev@gmail.com</a>> wrote:<br><br><blockquote type="cite">Hi!<br><br>Propose to move the MismatchedDeallocator checker from unix.* to cplusplus.* group if you don't think it's too late. This check is specific for C++.<br><br>-- <br>Anton<br><br><MismatchedDeallocator_rebase.patch>_______________________________________________<br>cfe-commits mailing list<br><a href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits</a><br></blockquote><br></blockquote></div><br></div></blockquote></div><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div></blockquote></div><br></div></blockquote></div><br></div></div></blockquote></div><br></div></blockquote></div><br></body></html>