39 results found

1. Add Cognitive Complexity as metric

   Sonar released in 2017 a new way to calculate the complexity of code. This way of measuring complexity is more practical than cyclomatic complexity, and helps to improve the understandability and readability of code.

   https://www.sonarsource.com/docs/CognitiveComplexity.pdf

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

2. Option for output in "Serif" format

   A couple of customers have asked for results in the "serif" format as specified at https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.pdf. Right now we are planning to try to do as much as we can in a post-processing step, but it would be incredibly convenient if we could just get that information out of the box.

   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…)
   under review  ·  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

3. Reinstate detection of unused headers

   Messages 766, 964 and 966, for reporting where headers have been included in a module but not apparently used, have all been removed since PC-lint 9 and I can find no indication why on this site, nor in the PC-lint plus manual. This was a very useful feature. Can it be reinstated?

   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…)
   under review  ·  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

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

5. Value tracking simultaneously assumes enums both can and cannot take any value

   In the following snippet I've defined a basic assertion macro and an enum, with an external function that returns a value typed by that enum. I wish to verify that the returned value is a valid enumerated value.

   Firstly, if we remove both assertions below then there are no warnings generated, despite the fact that an out of bounds access on the printf is possible.

   If you add both assertions then the warning described inline occur: a warning on the first assertion claims that the result can be predetermined. If we assume that enums can only take their enumerated values then this could be a reasonable claim, albeit unsafe in my opinion.

   However, if you remove the first assertion then a warning is generated on the printf line indicating that a possible out-of-range access at position -2147483648 occurs. In this case, Lint assumes that enums can take any possible value. In my opinion this is the desired result, however it conflicts with the previous paragraph.

   #include <stdlib.h>
   #include <stdio.h>
   #include <stdint.h>
   
   typedef enum MyEnum_e
   {
     ENUM_VAL_0 = 0,
     ENUM_VAL_1 = 1,
     ENUM_VAL_COUNT
   } MyEnum_t;
   
   MyEnum_t f(void);
   
   #define MY_ASSERT(cond) if (!(cond)) exit(0)
   int main()
   {
       static int32_t the_array[(uint32_t)ENUM_VAL_COUNT] = { 0, 1 };
       MyEnum_t the_value = f(); //some function call, perhaps external. consider f() could return (MyEnum_t)(-1);
       MY_ASSERT(the_value >= ENUM_VAL_0); //causes warnings 2650 and 587, incorrectly claims predicate '>=' can be pre-determined and always evaluates to true.
       MY_ASSERT(the_value < ENUM_VAL_COUNT);
       (void)printf("%i", the_array[the_value]); //If you comment out the first assertion above then this line triggers "warning 676: possibly indexing before the beginning of an allocation, inference yields -2147483648"
   
       return 0;
   }
   

   In the following snippet I've defined a basic assertion macro and an enum, with an external function that returns a value typed by that enum. I wish to verify that the returned value is a valid enumerated value.

   Firstly, if we remove both assertions below then there are no warnings generated, despite the fact that an out of bounds access on the printf is possible.

   If you add both assertions then the warning described inline occur: a warning on the first assertion claims that the result can be predetermined. If we assume that enums can only take their enumerated values… 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…)
   under review  ·  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

6. Value tracking arrives at incorrect conclusion when incrementing variables in loop conditions

   Consider the following program:

   #include <stdlib.h>
   #include <stdint.h>
   
   #define MAX_VAL (6)
   
   int main()
   {
       uint32_t val = 0;
   
       do
       {
       }
       while(++val != MAX_VAL);
   
       if(MAX_VAL == val)
       {
         exit(0);   
       }
   
       return 0;
   }
   

   This program is guaranteed to exit before reaching the return, however lint claims it is guaranteed to never execute the body of the the if statement:

   info 774: boolean condition for 'if' always evaluates to 'false' (involving variable 'val')
   supplemental 831: binary operator yields 0 (line 15)
   supplemental 831: increment yields 1 (line 13)
   supplemental 831: initialization yields 0 (line 8)
   supplemental 831: integral conversion yields 0 (line 8)
   supplemental 831: integral conversion yields 6 (line 15)
   supplemental 893: expanded from macro 'MAX_VAL' (line 4)
   

   I suspect Lint is confusing val++ for ++val which would make the warning correct.

   Consider the following program:

   #include <stdlib.h>
   #include <stdint.h>
   
   #define MAX_VAL (6)
   
   int main()
   {
       uint32_t val = 0;
   
       do
       {
       }
       while(++val != MAX_VAL);
   
       if(MAX_VAL == val)
       {
         exit(0);   
       }
   
       return 0;
   }
   

   This program is guaranteed to exit before reaching the return, however lint claims it is guaranteed to never execute the body of the the if statement:

   info 774: boolean condition for 'if' always evaluates to 'false' (involving variable 'val')
   supplemental 831: binary operator yields 0 (line 15)
   supplemental 831: increment yields 1 (line 13)
   supplemental 831: initialization yields 0 (line 8)
   supplemental 831: integral conversion yields

   … 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…)
   under review  ·  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. Relaxed parsing of *-e* inhibitions for multiple messages

   Compare the parser requirement for separating commas [#...

   -ecall(# [# ...], Function [,Function ...])
   -emacro(# [# ...], Symbol [,Symbol ...])
   -estring(# [# ...], String [,String ...])
   -esym(# [# ...], Symbol [,Symbol ...])
   -etype(# [# ...], Type [,Type ...])

   ...vs. [,#...

   -e(# [,# ...])
   --e(# [,# ...])
   -e{# [,# ...]}
   --e{# [,# ...]}

   ...which in my opinion makes usage a bit more difficult than necessary, as the two groups of inhibitions have slightly different requirements.

   While there probably are good reasons for not requiring a separating comma for the first group of inhibitions, the second group could easily get relaxed parsing such the separating comma becomes optional, i.e.

   -e(# [[,]# ...])
   --e(# [[,]# ...])
   -e{# [[,]# ...]}
   --e{# [[,]# ...]}

   In the long run, this could even be simplified to...

   -e(# [# ...])
   --e(# [# ...])
   -e{# [# ...]}
   --e{# [# ...]}

   ...finally resulting in the same syntax as the first group.

   Compare the parser requirement for separating commas [#...

   -ecall(# [# ...], Function [,Function ...])
   -emacro(# [# ...], Symbol [,Symbol ...])
   -estring(# [# ...], String [,String ...])
   -esym(# [# ...], Symbol [,Symbol ...])
   -etype(# [# ...], Type [,Type ...])

   ...vs. [,#...

   -e(# [,# ...])
   --e(# [,# ...])
   -e{# [,# ...]}
   --e{# [,# ...]}

   ...which in my opinion makes usage a bit more difficult than necessary, as the two groups of inhibitions have slightly different requirements.

   While there probably are good reasons for not requiring a separating comma for the first group of inhibitions, the second group could easily get relaxed parsing… 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…)
   under review  ·  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. 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

9. Make the program skip missing files in multi-file config

   Make the program skip missing files in multi-file config. Currently it stops on a missing file. This is for generated file that don't exist in the linting build.

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

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

11. generate a lint-config file to suppress warnings

    Automatically generate a lint-config file that suppresses any message as locally as possible. This would be very useful for the implementation of PC lint. It would also make it easier to update to a newer version. Many companies have a quality gate that requires that no warnings are included in the code. E.g. after updating to version 1.4.1, more than 800 warnings were generated in our project, with the same configuration. It would be useful to generate a lint configuration file, so that one can temporarily suppress the warnings when changing versions. One can then plan the solution of the issues and eliminate them step by step.

    Automatically generate a lint-config file that suppresses any message as locally as possible. This would be very useful for the implementation of PC lint. It would also make it easier to update to a newer version. Many companies have a quality gate that requires that no warnings are included in the code. E.g. after updating to version 1.4.1, more than 800 warnings were generated in our project, with the same configuration. It would be useful to generate a lint configuration file, so that one can temporarily suppress the warnings when changing versions. One can then plan the solution of the… more

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

12. Support ARM compiler v6 for Keil

    The PC-Lint Plus Configurator currently supports ARM compiler v5 for Keil. However, ARM v6 has been supported by Keil for some time, and so it would be useful if the Configurator did as well.

    Note that ARM v6 is based on Clang, which is already supported by the Configurator for GCC installations. However, this doesn't set up the correct options for use with Keil. The options for Keil + ARM v5 seem to mostly (but not entirely) work with v6, but "official" support would be better.

    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…)
    under review  ·  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

13. Enable opt-in assumptions about the initial values of static variables

    This condition doesn't seem to be detected by PC-lint Plus:

    include <stdint.h>

    include <string.h>

    typedef struct
    {
    uint8t one;
    uint8t two;
    uint8t three[18];
    } testt;

    static testt *mpdef;
    static testt *mpabc;

    void
    test (void)
    {
    // These manipulations should trigger a warning since both pointers are not initialized.
    mpdef->one = 1;
    mpabc->one = 2;
    }

    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…)
    under review  ·  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

14. [1.3] C99: 9027, 9036 messages are hard to filter out

    In the code below, it is very difficult to filter out the messages issued on our boolean type (unsigned8) because the message uses the essential type and we risk filtering out the true unsigned8 variables in this case. We are forced then to dupe PcLint into thinking boolean is actually of type _Bool.

    Moreover both messages don't show any symbols for the variables themselves. it would be nice to be able to use esym in such cases for specific enums or booleans, etype would also be great. The more info we have the greater control achieved with egrep too.

    Also same as -egrep(9027, "enum .* to ++"), it would be great if we could use -egrep(9027, "boolean .* to !") where boolean is (unsigned8).
    It would be also nice to use etype and/or esym for both cases which is not currently possible.

    /****************************/
    /lint -w3*/

    define FALSE (0u)

    typedef unsigned char boolean;
    typedef unsigned char uint8;

    static enum
    {
    SAFEHWDGSTATE0INIT = 0
    , SAFEHWDGSTATE1RUNTIME

    , SAFEHWDGSTATEPANIC
    } lsSafeHWdgStateen = SAFEHWDGSTATE0INIT;

    static boolean IsFailed_bl;
    static uint8 x;

    void cyclic(void);
    void cyclic(void)
    {

    switch(ls_SafeH_WdgState_en)
    {
      case SAFEH_WDG_STATE_0_INIT:
        IsFailed_bl = FALSE;
        x = 0;
        ls_SafeH_WdgState_en++;
    
        break;
      case SAFEH_WDG_STATE_1_RUNTIME:
        if (IsFailed_bl)
        {
          ls_SafeH_WdgState_en++;
        }
        break;
      case SAFEH_WDG_STATE_PANIC:
        ls_SafeH_WdgState_en++;
        break;
      default:
        if ((x == 5u)&&(IsFailed_bl))
        {
          /* do something */
        }
        if ((IsFailed_bl)&&(x == 4u))
        {
          /* do something */
        }
        break;
    }
    

    }
    /*****************************/

    In the code below, it is very difficult to filter out the messages issued on our boolean type (unsigned8) because the message uses the essential type and we risk filtering out the true unsigned8 variables in this case. We are forced then to dupe PcLint into thinking boolean is actually of type _Bool.

    Moreover both messages don't show any symbols for the variables themselves. it would be nice to be able to use esym in such cases for specific enums or booleans, etype would also be great. The more info we have the greater control achieved with egrep too.

    Also… more

    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…)
    0 comments  ·  Edit…  ·  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

15. Improve support for AUTOSAR

    As of PC-lint Plus 1.3, basic support for the AUTOSAR coding guidelines has been added. However, 107 rules of 301 that are tagged "automated" or "partially automated" by AUTOSAR are marked "not currently supported" in the file au-autosar.lnt. This still makes it difficult to claim adherence to the standard without trying to implement long and error-prone review checklists.

    Please improve the number of supported AUTOSAR rules.

    22 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…)
    started  ·  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

16. Ignore -d command line option if empty (-d"")

    We are using CMake build system to generate the command-line options and run PC-Lint. The command line options are generated after the configuration stage of CMake and it can happen that the value of a define is not known yet at that stage:

    $<$<BOOL:OFF>:BUILD_TESTS>

    If BUILD_TESTS is disabled, the command line option will be empty:

    -d"$<$<BOOL:OFF>:BUILD_TESTS>" gets converted to:
    -d""

    When you run pclp64 -d"" the following error appears:

    --- Module: /projects/alpha/alpha.c (C)
    <command line option> 1 error 5469: macro name must be an identifier

    #define 1

    My request is to check if -d argument is empty, and if it's empty to just ignore it instead of evaluating it to "#define 1"

    We are using CMake build system to generate the command-line options and run PC-Lint. The command line options are generated after the configuration stage of CMake and it can happen that the value of a define is not known yet at that stage:

    $<$<BOOL:OFF>:BUILD_TESTS>

    If BUILD_TESTS is disabled, the command line option will be empty:

    -d"$<$<BOOL:OFF>:BUILD_TESTS>" gets converted to:
    -d""

    When you run pclp64 -d"" the following error appears:

    --- Module: /projects/alpha/alpha.c (C)
    <command line option> 1 error 5469: macro name must be an identifier

    #define 1

    My request is to check if -d argument is empty, and if it's… 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…)
    0 comments  ·  Edit…  ·  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

17. allow user-supplied function semantics to override function inputs

    For functions which the user has supplied function-wide semantics, I would like to see a flag/mode that allows the provided semantics to essentially "override" the inputs to the function.

    For example, if I provide a "np" semantic for a function, I don't want to see a message for possible use of NULL pointer generated within the function; I have already provided a semantic that the parameter is not NULL. Similarly with integral parameters, if I provide a semantic that "1n < 2" and then use that parameter to index into a 2 element array, I don't want to see "possible index out of range" by a billion because the input is considered "unknown".

    This is clearly predicated on the semantics already being verified as called, as they are through messages 418, 419, 422, 426 and the like.

    For functions which the user has supplied function-wide semantics, I would like to see a flag/mode that allows the provided semantics to essentially "override" the inputs to the function.

    For example, if I provide a "np" semantic for a function, I don't want to see a message for possible use of NULL pointer generated within the function; I have already provided a semantic that the parameter is not NULL. Similarly with integral parameters, if I provide a semantic that "1n < 2" and then use that parameter to index into a 2 element array, I don't want to… more

    4 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

18. Consider adding reporting capabilities to PC-LINT Plus

    Most competing tools can generate MISRA compliance reports at the push of a button.
    With PC-LINT 9.0L it is a rather tedious procedure, e.g. running with ++efreeze, parsing text output and generating a result.
    Not up to date in 2017.

    19 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…)
    under review  ·  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

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

    30 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

20. 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 a good amount of work. But work that IMO many users of lint, particularly those working in safety-critical fields such as automotive, energy, medical devices, defense, etc. would love to see.

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

    19 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…)
    under review  ·  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