Tried to simplify the situation as much as possible. So I have a class:
class C
{
int * field;
public:
C() : field(nullptr) {}
void init(int* f) { field = f; }
int getI1() { return *field; }
int getI2() { return *field; }
};
which generates 2 Lint warnings 613 (Possible use of null pointer 'C::i'...)
I know that "field" won't be null when getI1() or getI2() are called. And unfortunately I cannot initialize it in constructor. So I want to suppress Lint warnings. I can do it like this
class C
{
int * field;
public:
C() : field(nullptr) {}
void init(int* f) { field = f; }
int getI1() { return *field; } //lint !e613
int getI2() { return *field; } //lint !e613
};
but in my real case:
1) There are rather many such classes and each class has many functions that use this pointer.
2) My managements doesn't allow me to add too many lint comments in the code.
So my question: does anyone know a command-line option that will let me tell Lint "I know the code is not best, just stop checking this particular member variable for null"?
Something similar to -sem parameter, maybe?
It seems that after the constructor has run, you have an instance that is not usable (will crash if you call getT1() or getT2()). That's not something that I like at all.
Much better to have a constructor C(int* f). Problem goes away. This is a case where the warning is entirely justified and warns you of bad code, so the bad code should be fixed.
That's the wrong way to handle it (even if I knew such command line parameter).
PC-Lint warns you correctly about that
may unintentionally dereference a
nullptr
.Just trying to suppress1 that waning isn't a very good idea, since the call of the
init()
function isn't mandatory.The correct way to get rid of it is to add an explicit check like
There's no other way than just wading through them and refactor that bad code.
That's a good policy. They spent the money to install the SCA tool for reasons, and want the code being improved.
If that collides with the time you've got available doing so, ask them to establish a task that allows you to accomplish that.
If you just want to concentrate on other (more important stuff) reported by PC-Lint, use
grep
or alike tools to filter out what you don't want to see ATM. But don't establish a command line parameters to suppress them completely. That are things that will be forgotten forever and never be touched or approached at later stages again.1 Suppressing any errors or warnings given by a SCA tool like PC-Lint defeats the whole purpose of it, unless you're absolutely sure the tool gives you a false positive. Otherwise your company could simply save the money spent for the licenses, and stick to the bad coding habits.
I know that code is bad, should be fixed and so on. Unfortunately I cannot do it right now (because of huge amount of effort for one person and highly risky changes), but those errors were overwhelming other, sometimes more critical, problems
I found out that to suppress this warning in one line you can do: