Skip to content

General

← Customer Feedback for PC-lint Plus

I suggest you ...

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

  • When an admin closes an idea you've voted on, you'll get your votes back from that idea.
  • You can remove your votes from an open idea you support.
  • To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".
(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

9 results found

  1. Restore the information available in the original Gimpel website.

    The original Gimpel web site contained a lot of valuable information.
    That seems to have disappeared . Could you restore that?
    You even have links in the discussions to the original Gimpel site that are now dead. Their web site was very useful.

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close

  2. Fix Note 952 for array[] vs. MISRA C++:2008 Rule 7-1-1

    Rule 7–1–1 (Required) states "A variable which is not modified shall be const qualified"
    PC-lint Plus issues note 952 (as a violation of rule 7-1-1) for function parameters including array[] or const array[].
    However in C++, array[] or const array[], cannot be qualified also as array[const] as in C99.

    Technically, note 952 should not be issued for array[].

    Note, that the obvious workaround of replacing array[] with *const array, is not really a solution
    as it triggers note 9016 (performing pointer arithmetic via addition/subtraction) in most cases
    for violation of MISRA C++ required Rule 5-0-15 (Array indexing shall be the…

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    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)
    Close
    Close
    declined  ·  AdminPC-lint Plus Support (Admin, Vector Informatik GmbH) responded

    Hi Charles, 

    In this case the recommendation is to use * const Array mentioned previously instead of uint8_t Array[]. Which would prevent unintended assignment to Array.

    We issue 952 to:

    1. Alerts the programmer to cases where const can be employed to prevent the variable from being unintentionally modified (the primary point of the elective note)
    2. MISRA C++ Rule 7-1-1 states that "a variable which is not modified shall be const qualified" and does not contain an exemption for parameters declared as arrays.

    If you want to suppress message 952 where a function parameter is declared as an incomplete array type. You can do so with the option:

    +misra_interpret(c++2008, permit unmodified non-const incomplete array parameters)

    This option is documented in section 4.7 of the Reference Manual.


    Best,

    PC-lint Plus Technical Support

  3. Refine note 952 to cope with array[] function parameters for C++

    Note 952 is issued for "parameter symbol of function symbol".

    C99 supports function parameters of the form param[const], C++ does not.

    MISRA C++:2008 Rule 5–0–15 (Required) states "Array indexing shall be the only form of pointer arithmetic". This implies that when a function performs array indexing, the array cannot be passed (syntactically) as a pointer and it has to be passed as array[].

    But then PC-lint issues a violation of Rule 7–1–1 (Required) "A variable which is not modifed shall be const qualifed."

    and as it seems there is no way around it - either 7-1-1 or 5-0-15 has…

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close

  4. program_info in PcLintPlus

    We used the program_info output to check for example the naming of variables. It would be great if this could be added to PCLintPlus.

    0 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close

  5. else-branch with empty debug statement

    I have a lot of debug message options in my code.

    ifdef DO_DEBUG

    define DBG_INFO(txt) WriteLn(txt)

    endif

    void foo(UInt16 a)
    {
    if (a != 0)
    {
    DoSomething();
    }
    else
    {
    DBG_INFO("a = 0");
    }
    }

    With Lint 9.00L I get a note "960" Violates MISRA 2004Required Rule 14.10, else-branch must have a comment or action.
    However, the else branch is not empty. It contains code that is just removed by the preprocessor.
    I have seen some similar effects with asm statements where for lint I have done:

    define asm(txt)

    Only give a 960 note when the else branch is truly…

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    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)
    Close
    Close

  6. Ability to change message categories

    Support an option that allows the user to change the message category of a message from, for example, Warning to Error.

    4 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    3 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)
    Close
    Close
    declined  ·  AdminPC-lint Plus Support (Admin, Vector Informatik GmbH) responded

    The message category associated with every message ("error", "warning", etc.) cannot be changed. If the goal is to convey a heightened sense of severity for specific messages, -append option may be used to cause custom text to be appended to the message when it is issued. If the goal is to elicit a build failure by causing PC-lint Plus to terminate with a non-zero exit code when particular messages have been issued, the -zero_err option can be used. See the description of this option for more information. If the goal is to cause the output to conform to the format expected by an IDE integration (which may recognize errors and warnings but have no concept of elective notes), see the -format_category option.

  7. optional timeout flag if processing a source takes too long

    Would it be possible to set a timeout at the
    command line when processing a single source file?

    Some files are simply too complex to be linted.

    It would be great if a user could cause flexelint
    to report a timeout condition if it cannot finish
    processing a file within a set time limit.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close

  8. Relax warning 747 for literals

    Given this code:

    include <stdio.h>

    include <string>

    void test()
    {
    std::string mystr("Hello World");
    char c;

    c = mystr[1];
printf("char: %c", (int)c);

    }

    Lint produces this output:

    c = mystr[1];

    main.cc 9 Info 747: Significant prototype coercion (arg. no. 1) int to
    unsigned log

    It seems unreasonable for this message to be emitted for a literal. The compiler obviously will convert to the properly sized argument.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close

  9. Dependency generation

    I try to run lint before the compiler, generally the error message are more useful and of course lint is more through. However, my make makes use of automatic dependancy generation (the compiler generates a list of files that the source being compiled depends on). This mean I end up running the compiler twice. Once to generate the dependancy list before lint and a second time to generate code after lint.

    This would all be well except that when the compiler runs into a problem during dependency generation it spits out obscure error messages. If I could get lint to…

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    declined  ·  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)
    Close
    Close
  • Don't see your idea?

General

Categories

Feedback and Knowledge Base

(thinking…)