General

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.

  1. 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…)
    Password icon
    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.

  2. 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…)
    Password icon
    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).

  3. 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…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    0 comments  ·  Flag idea as inappropriate…  ·  Admin →
  4. 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…)
    Password icon
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    already exists  ·  1 comment  ·  Flag idea as inappropriate…  ·  Admin →
  5. 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…)
    Password icon
    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