Lint sees that ownership of allocated memory is taken by a constructor if the owning object isn't "new'd". But if the owning object is "new'd", then Lint does not understand this. See the example below, which works in the online demo.

This was discussed in this thread, as well as several others:
http://www.gimpel.com/Discussion.cfm?ThreadID=808

//lint -e438, -e529, -e1502, -e1712, -e1788, -e714

include <memory>

struct A { A(char ){}; };
void g( )
{
// This results in a 429 warning.
char * ptr1 = (char ) malloc(10);
A *a1 = new A(ptr1);

// This does not result in a 429 warning.
char * ptr2 = (char *) malloc(10);
A a2(ptr2);
}

We had a construction like;
len = strlen(value);
p = malloc(len)
strcpy(p, value)

since we allocate 1 byte too little the strcpy will always cause a buffer overrun. But lint 9.00k did not detect it. Since this was only called with data read from files, it was detected when I added a call where value was a string literal

It seems like lint is good in arithmetic and less good in algebra
When it have a string literal of a known length it correct calculates the overrun, but if value is of unknown length it can't deduct that the overrun happens.

Rgds Lars

In some code constructs, value tracking can become confused by mutually-exclusive code paths. This is also known as the "correlated variables" problem, and can cause erroneous Warning 661 (pointer access out of bounds) alerts.

I'd like to see PC-Lint be given the ability to determine mutually-exclusive code paths and remove these spurious warnings.

The following code sample demonstrates this:

include <stdbool.h>

include <stdint.h>

include <string.h>

/lint ++fan ++fas/
typedef struct {

uint8_t     One0[2];

uint8_t     Two;

uint8_t     One2[2];

} DATA_TYPE;
/lint --fas --fan/

typedef enum { CLASSONE, CLASSTWO } DATA_CLASS;

bool SetOrClear(DATATYPE *as, const DATACLASS type, const sizet byte, const uint8t mask, const bool state)
{

uint8_t *pset;

size_t ofs;


switch (type) {

case CLASS_ONE:

    if (byte < sizeof(as->One0)) {

        pset = as->One0;

        ofs  = byte;

    } else {

        ofs = byte - sizeof(as->One0);

        if (ofs >= sizeof(as->One2)) {

            return false;

        }

        pset = as->One2;

    }

    break;

case CLASS_TWO:

    if (byte >= sizeof(as->Two)) {

        return false;

    }

    pset = &as->Two;

    ofs  = byte;

    break;

default:

    return false;

}

if (state) {

    pset[ofs] |= mask;

} else {

    pset[ofs] &= ~mask;

}

return true;

}

Although an explicite cast looks like the programmer knew, the intended behaviour may need two casts.
I wanted to "infinitely" accumulate possibly small, possibly negative increments (float i) in a modulo counter consisting of an unsigned integer variable (uint32_t n) and a real variable (float f) for the fractional part.

f += i;
n += (uint32t)f; // should read n += (uint32t)(int32t)f;
f -= (int32t)f;

worked with several compilers for PC platforms (gcc, lcc32, VS C++) and with TI''s c6000 compiler for an OMAP L138, but the counter failed to decrease with TI's ARM5.1 compiler for the 7R4 core.

This is implementation defined behaviour as of C99 6.3.1.4, but none of the compilers emitted a warning nor does lint.

Sometimes it would be nice to suppress a message for all derived classes.

For example:

class X
{
virtual void f() = 0;
};

class Y : public X
{
void f() {}
};

class Z : public X
{
int i;
void f(){++i;}
};

I would like to be able to put the following comment with the declaration of X:
//lint -esym(1961,[X]::f) //1961 - virtual member function 'Symbol' could be made const

Where I use [X] as syntax to define X and all classes derived from it.
So when a sub class dos not use the function f to the full extend lint knows from the comments that came with X

Also for other messages it would be nice to inhibit it for a family of classes.