Skip to content

General

39 results found

  1. Correct a possible oversight in the Warning 529 and/or 438 behavior

    If a character array is set to a value (using a function), which is never subsequently used or returned the WARNING 529 or WARNING 438 should be generated.

    Given the following file, main.c
    1 #include <string.h>
    2
    3 int main ( void )
    4 {
    5 int un1 = 0;
    6 char un2[10] = {0};
    7 char un3[10] = {0};
    8

    9
    10 strcpy(un2,"Hello");
    11
    12 return 0;
    13 }

    flexelint does not see the variable as unused below. Notice that Line 5 and Line 7 generate the 529, but line 6 is ignored. A 438 might work as well.

    5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. Add an option to identify undefined behavior

    The C99 standard (Appendix J) identifies almost 200 forms of undefined behavior (UB). For many, many reasons, UB is basically the most egregious form of coding error. It is totally preventable, and the effects can be most devastating.

    Even though not all kinds of UB can be detected by a static analysis tool, many are, and other tools do this pretty well.

    Piggy-backing onto this -- would also be nice to identify implementation-defined behaviors (e.g. bit position of bit-fields) and unspecified behaviors.

    As these are all part of the standard, it doesn't seem too hard to do intellectually, it's just…

    19 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    under review  ·  1 comment  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. Preprocessor output for a specific code section

    The "-p run just the Preprocessor" option is very handy, but for me it often generates too much information to pour though when I'm trying to diagnose a specific macro issue.

    It would be great if the preprocessor output could be enabled for a section of code, and send the output to a file and/or standard out.

    e.g.:
    //lint -p+
    SOMECOMPLEXMACRO(a,b,c,d,e);
    //lint -p-

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. Display all options currently in effect (What Options am I using here)

    Although "-vo" and "lint usual arguments ?" are useful, they produce a lot of information, including information that sometimes could be considered 'what was noise' such as temporary error suppressions "-save, -e123, -restore"

    It would be great if you could add a feature where I could display all options, suppressions, flags, etc. in effect at a specific point in a source file that have been:
    a) changed from the defaults, or
    b) changed since the last "-save"
    c) changed in this file

    for example:
    //lint -save
    //lint -e123
    //lint -esym(456, FooBar)
    ...
    /lint -save -e789 */ MACRO /lint…

    10 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Specify precompiled header -pch .lph output directory

    Currently, the xxx.lph precompiled header file is outputted/saved in the same directory as the xxx.h header file, which causes the (often very large) file to be unnecessarily included in source code only backups.

    Ideally it would be possible to designate the directory that the .lph precompiled output file is stored in, such as the debug/release build object file directory or a temporary directory.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. documentation suggestion: sample function names

    The documentation sometimes includes sample function names that can be misread as keywords/parameters, for example:
    //lint -sem( push, custodial(1))
    "push" is often a keyword, for example:

    pragma pack(push, 1)

    pragma warning(push)

    the examples in the guide are great, but sample function names that look like they could be parameters is sometimes confusing for me.

    Also, if the sample function names were odd-ball and had mixed case, I think it would be a bit clearer, such as FooBar, MyFunc

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. Bitfield size isn't error checked by Lint

    Greetings,
    I've been using Lint for the past 5 years and it's been a very useful tool for me. However, today I discovered an error in my C code that wasn't caught by Lint, and it may be useful if it could be flagged. The error is trying to divide a variable in a structure definition into bitfields where the combined size of the bitfields exceeds the size of the underlying variable.

    For example, my bad code was like this:

    typedef struct dummy_struct
    {
    unisgned char field1: 6,
    field2: 6,
    field3: 1,
    field4: 1;
    } DUMMY;

    So, basically, I was…

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. Use a fixed release cycle

    Customers could plan better, if they knew you have 2 or 4 releases per year.
    Right now it´s totally unpredictable.

    9 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. Add support for pthread_mutex_trylock() semantics

    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);
    }
    
    17 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Allow Lint to see that constructor takes ownership of memory.

    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.…

    16 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. Detect -e Options and -save without -restore

    -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.

    16 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    In PC-lint Plus, suppression options inside a source module do not “leak” to subsequent modules so this is less of an issue for PC-lint Plus than it was for PC-lint but we do plan to add a warning for -save options that do not have corresponding -restore options in a future update to PC-lint Plus.

  12. Missing data overrun detection

    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…

    10 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. Resolve the "correlated variables" problem in value tracking

    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 {
    uint8t One0[2];
    uint8
    t Two;
    uint8t One2[2];
    } DATA
    TYPE;
    /lint --fas --fan/

    typedef enum { CLASSONE, CLASSTWO } DATA_CLASS;

    bool…

    9 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. Out Of Bounds Checking at Start Of Array

    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]
    *buffer
    ptr = 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]
    *buffer
    ptr = 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.

    5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    planned  ·  2 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. to add a new warning to find use of an explicite cast from real to unsigned int.

    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 -= (int32
    t)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…

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. Variable could be declared as const ref

    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

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. Extra initializer/cleanup semantics

    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

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. Be able to suppress for derived classes

    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…

    5 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Find message inhibitions inside files that have no effect

    Sometimes the following happens:
    Code is created with a deliberate violation of a lint message.
    The message in inhibited with a comment in the code.
    However, it often happens comments are not updated with code.
    So the reason for the inhibition may be removed and the inhibition stays.

    It would be nice to find such "broken" inhibitions, (that have no effect on the resulting messages even when all other inhibitions are disabled).
    Maybe this search can be a result of executing pc-lint with a special flag.

    This way the code can be cleaned of old inhibitions.

    48 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
2 Next →
  • Don't see your idea?

General

Categories

Feedback and Knowledge Base