<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I am all for adding 'generic' category
and moving new generic checkers into it. There are many of generic
checkers in the future checkers list ('different' category).<br>
<br>
As for me I'd also copied generic checkers from the 'unix'
('alpha.unix') category to 'generic' ('alpha.generic') and added a
warning-notification to scan-build that, when one of this checkers
is used, informs that a checker will be deprecated in the future
release. The 'unix' is the only category that do not match its
contents and remapping do not solve this problem. In addition,
with the appearance of 'generic' category the 'unix' category with
its generic checkers will look more confusing.<br>
<br>
</div>
<blockquote
cite="mid:E01BC676-F7AD-42F4-88C9-965AF701F8B2@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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
moz-do-not-send="true" 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
moz-do-not-send="true"
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
moz-do-not-send="true"
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 moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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'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
moz-do-not-send="true" 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
moz-do-not-send="true" 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
moz-do-not-send="true"
href="mailto:cfe-commits@cs.uiuc.edu">cfe-commits@cs.uiuc.edu</a><br>
<a
moz-do-not-send="true"
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>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Anton</pre>
</body>
</html>