As described in http://www.gimpel.com/Discussion.cfm?ThreadID=3793 this functionality is needed.

For example, this function results in lint warning 455 (A thread mutex that had not been locked is being unlocked):

bool IsLocked()

{

    int retStat = pthread_mutex_trylock(&m_pthreadMutex);

    if (retStat == 0)

    {

        // Mutex was not locked, but is now.

        pthread_mutex_unlock(&m_pthreadMutex);

        return (false);

    }

    else if (retStat == EBUSY)

    {

        // Mutex is already locked.

        return (true);

    }

    return (false);

}

Given this code:

include <stdio.h>

include <string>

void test()
{

std::string mystr("Hello World");

char c;


c = mystr[1];

printf("char: %c", (int)c);

}

Lint produces this output:

c = mystr[1];

main.cc 9 Info 747: Significant prototype coercion (arg. no. 1) int to

unsigned log

It seems unreasonable for this message to be emitted for a literal. The compiler obviously will convert to the properly sized argument.

-e Options without surrounding -save/-restore in the same file shall be warned.
Also a -save without -restore in the same file or same block level shall be warned.

This is 'out-of-bounds' is detected:

unsigned char buffer[5];
unsigned char* buffer_ptr = &buffer[4];

++bufferptr; // ERROR! now points to 1 byte after &buffer[4]
*bufferptr = 0x12; // assign to memory outside of buffer[]

This 'out-of-bounds' is NOT detected:

unsigned char buffer[5];
unsigned char* buffer_ptr = &buffer[0];

--bufferptr; // ERROR! now points to 1 byte before &buffer[0]
*bufferptr = 0x12; // assign to memory outside of buffer[]

As 'buffer_ptr' has been 'bound' to 'buffer' via the assignment I would have expected PC-lint to have detected this.

//lint -A(C99)
typedef unsigned char uint8;
typedef _Bool bool;

const uint8 a = 100;
const uint8 b = 200;
int main(void)
{
bool test;
test = (a==b);
}
Report error 1564 or 921 (cast from int to bool)

Lint should know that the assignment of
test = (a==b) is save on C99.
Additionally, in our case it could not be deactivated by -estring(921,"cast from int to bool")

It would be nice to specify which members are deleted or uinitialzed:

class X
{
int i;
int j;
float* k;
void cleanInts() { delete i;delete j;}
~X(){delete k;cleanInts();}
};

in this case -sem(X::cleanInts,cleanup) won't help.
I propose the following semantics:
-sem(X::cleanInts,cleanup(X::i,X::j)) where cleanInts should free X::i and X::j

Similar to message: 953 - Variable 'Symbol' (Location) could be declared as const

I would like to see a message for the following situation:

struct X
{
int i;
};

struct Y
{
const X& f();
};

int g( Y y)
{
const X x = y.f();
return x.i + 5;
}

In this case variable x could be declared as const ref.
When the intialization of a const variable is done with an other const variable or a function returning a const reference this message (or maybe two separete messages) could be issued

Support an option that allows the user to change the message category of a message from, for example, Warning to Error.