Actually neither of the checkers from the 'unix' group are Unix
specific. Neither is the majority of 'alpha.unix' group.
unix.API - not all handled functions are Unix/POSIX specific
open (POSIX)
pthread_once (POSIX)
calloc (ISO C)
malloc (ISO C)
realloc (ISO C)
alloca (4.3 BSD ?)
unix.Malloc - malloc is a C standard function
unix.MallocSizeof - malloc is a C standard function
unix.MismatchedDeallocator - handles C/C++ standard functions
unix.cstring.BadSizeArg - strncat is a C standard function
unix.cstring.NullArg - not all handled functions are Unix/POSIX specific
strlen (ISO C)
strnlen (POSIX)
strcpy (ISO C)
strncpy (ISO C)
strcat (ISO C)
strncat (ISO C)
strcmp (ISO C)
strncmp (ISO C)
strcasecmp (POSIX)
strncasecmp (POSIX)
alpha.unix.MallocWithAnnotations - malloc is a C standard function
alpha.unix.SimpleStream - fopen and fclose are a C standard functions
alpha.unix.Stream - all handled functions are a C standard or standard
extension functions
alpha.unix.cstring.BufferOverlap - not all handled functions are
Unix/POSIX specific
memcpy (ISO C)
mempcpy (GNU extension)
alpha.unix.cstring.NotNullTerminated - all handled functions are a C
standard or standard extension functions
alpha.unix.cstring.OutOfBounds - all handled functions are a C standard
or standard extension functions
Alltogether only alpha.unix.Chroot and alpha.unix.PthreadLock remain
pure 'unix' checkers.
I intend to create 'generic' and 'alpha.generic' groups and to move not
Unix specific checkers there. OK to move in this direction?
All this checker rebase activity was inspired by my current work on the
improved lists of actual/alpha/potential checkers.
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.
On Mar 19, 2014, at 5:10 PM, Jordan Rose <[email protected]
<mailto:[email protected]>> wrote:
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.)
My inclination is to leave it where it is right now.
(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.)
Jordan
On Mar 19, 2014, at 17:08, Ted Kremenek <[email protected]
<mailto:[email protected]>> wrote:
You didn’t really answer my question. What is the right answer here?
On Mar 19, 2014, at 2:05 PM, Jordan Rose <[email protected]
<mailto:[email protected]>> wrote:
"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.
Jordan
On Mar 19, 2014, at 13:55, Ted Kremenek <[email protected]
<mailto:[email protected]>> wrote:
By that argument, does it belong in “unix”? What about
Windows-specific allocators?
On Mar 19, 2014, at 1:45 PM, Jordan Rose <[email protected]
<mailto:[email protected]>> wrote:
It's /currently/ specific to C++, but I'm not sure it's
/inherently/ 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.
Jordan
On Mar 19, 2014, at 13:27, Ted Kremenek <[email protected]
<mailto:[email protected]>> wrote:
Seems fine to me.
On Mar 19, 2014, at 1:12 PM, Anton Yartsev
<[email protected] <mailto:[email protected]>> wrote:
Hi!
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++.
--
Anton
<MismatchedDeallocator_rebase.patch>_______________________________________________
cfe-commits mailing list
[email protected] <mailto:[email protected]>
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
--
Anton
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
