I've been writing cppcheck library rules for some of my core C libraries.
One thing that I'd love to check for is a case where a constructor is
called, but isn't balanced by a call to a destructor (sort of analogous
to the resource tag for allocators/deallocators).
A typical (correct) function would look like:
void f( void )
{
str s;
str_init( &s );
/* do something */
str_free( &s );
}
I'd love to catch when the str_free() has been forgotten (or even if
str_init() is forgotten in a path containing str_free()). There's a lot
of analogy with the alloc/dealloc resource pattern, but clearly that
pattern won't work in this case.
Is there a way to convince cppcheck to look for these sorts of patterns?
Thanks in advance.
Chris.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
AFAIK it is currently not possible to get Cppcheck to verify constructs like this via library configuration.
Maybe it is worthwile to request this as a feature in Trac.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've been writing cppcheck library rules for some of my core C libraries.
One thing that I'd love to check for is a case where a constructor is
called, but isn't balanced by a call to a destructor (sort of analogous
to the resource tag for allocators/deallocators).
A typical (correct) function would look like:
void f( void )
{
str s;
}
I'd love to catch when the str_free() has been forgotten (or even if
str_init() is forgotten in a path containing str_free()). There's a lot
of analogy with the alloc/dealloc resource pattern, but clearly that
pattern won't work in this case.
Is there a way to convince cppcheck to look for these sorts of patterns?
Thanks in advance.
Chris.
AFAIK it is currently not possible to get Cppcheck to verify constructs like this via library configuration.
Maybe it is worthwile to request this as a feature in Trac.