General

  1. Make price reasonable for solo developers!

    I was a huge ambassador for PC-Lint 6 - 9 in the past, beta tested 8 and 9 and loved the product, but as a hobbyist developer, I simply cannot afford PC-Lint Plus, whereas I could afford to buy PC-Lint in the past. Can you re-think your licensing costs for the benefit of people like me who wish to be professional in our mindset (i.e. using static analysis etc!) but don't have the budget for PC-Lint Plus (but did for PC-Lint 9)

    16 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    already exists  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  2. Support for Barr Group standard?

    Hello,

    Does PC-Lint/PC-Lint Plus support analysis for the Barr Group standard?

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    already exists  ·  2 comments  ·  Flag idea as inappropriate…  ·  Admin →
  3. Additional parameter for elibcall/elibmacro

    As of now, you can't specify a concrete symbol for elibcall/elibmacro.
    But sometimes, you just don't want to risk disabling a message for all library macros/calls.
    So, it would be more secure, if the user could specify the library function/macro.

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →

    The -elibcall and -elibmacro options are designed for cases where the suppression is meant to apply to all library calls or library macros. If you want to suppress a message for a call to a specific function or for a specific macro, use the options -ecall and -emacro, respectively. Note that -ecall and -emacro can be used with library and non-library symbols.

  4. Add error 747 to -efunc

    As described in http://www.gimpel.com/Discussion.cfm?ThreadID=1132 you cannot easily suppress 747 Significant Prototype Coercion message for a specific function.

    I have static member function

    JTime JTime::seconds(int64_t sec);

    With following code:

    uint32_t my_time;
    JTime timeNeeded;
    ...
    timeNeeded = JTime::seconds(my_time); // <-- Error 747

    I would like something like this in lint options file to work:

    -efunc(747, JTime::seconds)

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →

    The -efunc option is meant to suppress messages within a particular function, the -ecall option suppresses messages within a call to a particular function. In the example you presented, the proper way to suppress message 747 is with the option -ecall(747, JTime::seconds).

  5. suppress 732 (loss of sign) when assigning unsigned bit fied values to an unsigned int

    In forum thread 4420 http://www.gimpel.com/Discussion.cfm?ThreadID=4420#1, a struct with an unsigned bit field value is assigned to another variable of the same type.
    It was said that this message 732 will be suppressed in 9.00L for such cases.

    I suggest to suppress the info in ALL cases where an unsigned bit field is assigned to ANY unsigned variable.

    Using the same code:

    typedef struct
    {
    unsigned int data : 16;
    } struct_t;

    struct_t foo = {0};

    unsigned int test = foo.data;

    1 vote
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  6. Support the widely used "#pragma once" directive

    Most compilers support the "#pragma once" directive. It would be very helpful if lint supports this directive too.

    2 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    already exists  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  7. Report differences between formal parameter names in header file prototypes and formal parameter namers in function definitions

    Formal parameter names in function prototypes are optional, but are often used, ideally with names that convey something about the value that should be passed. In C and C++, those names have prototype scope, go away after the prototype is parsed and processed, and are irrelevant to code generation--but a discrepancy between the name of the formal in the prototype and the corresponding name in the function definition can mislead a programmer seeing only the prototype and cause him or her to pass the wrong value. It would therefore be worthwhile for a lint program to remember the prototype formal…

    11 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    2 comments  ·  Flag idea as inappropriate…  ·  Admin →

    This functionality is provided in PC-lint Plus with messages 955 (parameter of forward declaration lacks a name), 9072 (parameter of function has different name than previous declaration) and 9272 (parameter of function has different name than overridden function).

  • Don't see your idea?

General

Feedback and Knowledge Base