9 results found

1. Add metric to find commented-out code
   3 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Default the pure ANSI/ISO C standard functions to -sem(..., pure)

   Several messages (e.g. 523 and 9007) deal with potential side-effects. This is great, but the implementation has room for improvement:

   if ((s != NULL) && ((strlen(s) > 0U)))

   I think it is safe to say that strlen() never has side-effects. But PC-lint Plus doesn't think so and issues message 9007 for the above piece of code.

   This issue applies to any function of the standard library. In most cases, e.g. strlen() or isnan() it should be clear whether or not the function has side-effects, most of these functions are implemented re-entrant. Unfortunately, as far I know, the C standard is not clear enough in this respect. Still, PC-lint Plus should default all ANSI/ISO C standard functions that are known to be pure to -sem(..., pure).

   Note that currently the -sem(... pure) option is way less useful if standard library functions are involved, as lint now often complains on calls to standard library functions. To work around this, every user of PC-lint Plus eventually comes up with some own list like:

   -sem(isalnum, pure) // <ctype.h>
   -sem(isalpha, pure) // <ctype.h>
   -sem(isblank, pure) // <ctype.h>
   -sem(iscntrl, pure) // <ctype.h>
   -sem(isdigit, pure) // <ctype.h>
   -sem(isgraph, pure) // <ctype.h>
   -sem(islower, pure) // <ctype.h>
   -sem(isprint, pure) // <ctype.h>
   -sem(ispunct, pure) // <ctype.h>
   -sem(isspace, pure) // <ctype.h>
   -sem(isupper, pure) // <ctype.h>
   -sem(isxdigit, pure) // <ctype.h>
   -sem(toupper, pure) // <ctype.h>
   -sem(tolower, pure) // <ctype.h>
   -sem(memchr, pure) // <string.h>
   -sem(memcmp, pure) // <string.h>
   -sem(strcat, pure) // <string.h>
   -sem(strcats, pure) // <string.h>
   -sem(strncat, pure) // <string.h>
   -sem(strncats, pure) // <string.h>
   -sem(strchr, pure) // <string.h>
   -sem(strrchr, pure) // <string.h>
   -sem(strcmp, pure) // <string.h>
   -sem(strncmp, pure) // <string.h>
   -sem(strcoll, pure) // <string.h>
   -sem(strcolll, pure) // <string.h>
   -sem(strcpy, pure) // <string.h>
   -sem(strcpys, pure) // <string.h>
   -sem(strncpy, pure) // <string.h>
   -sem(strncpy_s, pure) // <string.h>
   -sem(strerror, pure) // <string.h>
   -sem(strlen, pure) // <string.h>
   -sem(strnlen, pure) // <string.h>
   -sem(strspn, pure) // <string.h>
   -sem(strcspn, pure) // <string.h>
   -sem(strstr, pure) // <string.h>
   -sem(strtok, pure) // <string.h>
   -sem(strxfrm, pure) // <string.h>
   -sem(abs, pure) // <stdlib.h>
   -sem(labs, pure) // <stdlib.h>
   -sem(llabs, pure) // <stdlib.h>
   -sem(fabs, pure) // <stdlib.h>, <math.h>
   -sem(fabsf, pure) // <stdlib.h>
   -sem(fabsl, pure) // <stdlib.h>
   -sem(div, pure) // <stdlib.h>
   -sem(ldiv, pure) // <stdlib.h>
   -sem(lldiv, pure) // <stdlib.h>
   -sem(acos, pure) // <math.h>
   -sem(asin, pure) // <math.h>
   -sem(atan, pure) // <math.h>
   -sem(atan2, pure) // <math.h>
   -sem(ceil, pure) // <math.h>
   -sem(cos, pure) // <math.h>
   -sem(cosh, pure) // <math.h>
   -sem(exp, pure) // <math.h>
   -sem(floor, pure) // <math.h>
   -sem(fmod, pure) // <math.h>
   -sem(fpclassify, pure) // <math.h>
   -sem(frexp, pure) // <math.h>
   -sem(frexpf, pure) // <math.h>
   -sem(isfinite, pure) // <math.h>
   -sem(isinf, pure) // <math.h>
   -sem(isnan, pure) // <math.h>
   -sem(isnormal, pure) // <math.h>
   -sem(ldexp, pure) // <math.h>
   -sem(log, pure) // <math.h>
   -sem(modf, pure) // <math.h>
   -sem(pow, pure) // <math.h>
   -sem(signbit, pure) // <math.h>
   -sem(sin, pure) // <math.h>
   -sem(sinh, pure) // <math.h>
   -sem(sqrt, pure) // <math.h>
   -sem(tan, pure) // <math.h>
   -sem(tanh, pure) // <math.h>

   Note that other parts of PC-lint Plus also handle ANSI/ISO C standard items, e.g. manual.pdf page 134 lists all headers files that are treated as "ansi" libclass.

   Several messages (e.g. 523 and 9007) deal with potential side-effects. This is great, but the implementation has room for improvement:

   if ((s != NULL) && ((strlen(s) > 0U)))

   I think it is safe to say that strlen() never has side-effects. But PC-lint Plus doesn't think so and issues message 9007 for the above piece of code.

   This issue applies to any function of the standard library. In most cases, e.g. strlen() or isnan() it should be clear whether or not the function has side-effects, most of these functions are implemented re-entrant. Unfortunately, as far I know, the C standard is… more

   1 vote

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. Support caching of analyses (something similar to ccache)

   Linting a large amount of files takes some time. This is normally not an issue, when running the analysis on build servers. The speed of PC-lint Plus is generally acceptable.

   However, this is still a source of frustration and seemingly wasted time for developers, when linting large project locally. A typical workflow while working on code is that a developer will often run lint locally for small incremental changes. (while changing code or while fixing lint messages) Since PC-lint Plus has to run through all of the source files again to properly check global rules, it is frustrating to have to wait for exactly the same analysis for >100 files, when you have only changes in one. A caching function, similar to ccache would be very welcome there. Something like “same cpp file, same included headers, same options, ….” -> use previous analysis results.

   Linting a large amount of files takes some time. This is normally not an issue, when running the analysis on build servers. The speed of PC-lint Plus is generally acceptable.

   However, this is still a source of frustration and seemingly wasted time for developers, when linting large project locally. A typical workflow while working on code is that a developer will often run lint locally for small incremental changes. (while changing code or while fixing lint messages) Since PC-lint Plus has to run through all of the source files again to properly check global rules, it is frustrating to have… more

   6 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Add option to show messages found in header file only once

   Consider this: a.h contains 10 problems and is included in 10 modules.
   That leaves you with 100 lint messages in the log, when in reality there are only 10 problems to fix.
   So, having an option that shows messages in header files only the first time it is included would be really cool (and more honest in terms of MISRA violations).

   29 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  1 comment  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. 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 -restore */
   ...
   int foo()
   {
   //lint -ListOptions(save)
   }
   would tell me about -e123 and -esym(456, FooBar) but not -e456

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

   10 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

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

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. 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.
   char * ptr2 = (char *) malloc(10);
   A a2(ptr2);
   }

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

   16 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

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

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   0 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   planned  ·  AdminRobert Gamble (Software Engineer, Vector Informatik GmbH) responded

   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.

9. 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]
   *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.

   5 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   planned  ·  2 comments  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close