Skip to content

General

15 results found

  1. Plugins for IDEs: Eclipse/STM32CubeIDE, JetBrains CLion, and VS Code

    I have been spoiled by having other tools (clang-tidy, cppcheck, SonarLint, etc.) analyzing code "on the fly" in my IDE. If there is a nice GUI out there for PC-Lint Plus then I would like to know about it (so far I've only seen this unofficial one: https://github.com/Ayymoose/PC-Lint-GUI).

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  2. Introduce sem(...) syntax without function name requirement, e.g. -sem{pure} or -sem(!, pure)

    The use of the -sem(...) option is somewhat cumbersome, it requires to duplicate the function name, resulting in two issues:

    Copy-pasting the -sem(...) option may result in forgetting to adapt the function name.

    There is no way to put the -sem(...) option into a function name agnostic macro like ATTR_REENTRANT.

    -sem(..., pure) typically is congruent with reentrancy. In our code we have a macro ATTR_REENTRANT to mark functions that are reentrant (and thus inherently thread-safe). We now have to mark such functions with both macro and -sem(..., pure).

    I propose an additional syntax -sem{pure} and/or !sem(...) or -sem(!, ...) that…

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    Thank you for your feedback and working with us to come up with a resolution. This issue can be resolved by using the option:


    ++d"ATTR_REENTRANT=__attribute__((pure))"


    which will cause PC-lint Plus to expand the ATTR_REENTRANT macro to __attribute__((pure)) which PC-lint Plus will recognize and automatically be converted to a pure semantic as long as the fca flag is active (which it is by default).

  3. Port pclp_config.py to Python 3.7 or later and update the manual accordingly.

    The current manual describes using a Python program to configure PC Lin Plus: the config/pclp_config.py.
    This is a Python 2.7 program. Python 2.7 is no longer supported.
    Would be nice to update this program to support Python 3.7 or later.

    2 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  4. Support VS latest version

    If your online evaluator is anything to go by, your support of Visual Studio C++ is pretty out-of-date. It would also be nice if you supplied an installer for PC-Lint in the VS environment, instead of requiring the tedious hand-editing detailed elsewhere here.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    PC-lint Plus 1.4.1 supports and provides an automated configuration GUI for Microsoft Visual Studio 2019. Future versions of PC-lint Plus are expected to continue providing support for the latest versions of Visual Studio.

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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  6. Support for Barr Group standard?

    Hello,

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

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  7. Improved MISRA checking for projects with mixed C/C++ source code

    According to chapter 5.7 of the manual, PC-LINT determines the language from the file extension.
    Therefore, one could assume that in a mixed C/C++ project one would get MISRA C messages in C modules and MISRA C++ messages in C++ modules respectively.
    In reality this is not working, even if you use the –indirect option to help PC-LINT:

    common.h/* included in all modules to select MISRA standard based on language*/

    ifdef __cplusplus

    /lint –indirect(au-misra-cpp.lnt)/

    else

    /lint –indirect(au-misra3.lnt)/

    endif

    Depending on the order of the modules processed, you end up with MISRA C messages in C++ modules…

    7 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    In PC-lint 9, modules were processed one at a time and options appearing in one module would go on to affect the next module. If the first module was a C module, it would activate the options in au-misra3.lnt which would still be in effect when a C++ module was processed.

    This issue is resolved in PC-lint Plus where each module is analyzed independently of other modules and options activated within one module will not affect other modules.

  8. Using always same output format for all messages

    When you use your own output format, that all messages has the same format.

    When you use:
    -"format=%f %l %t %n; %m"

    some messages looks like:
    0 Info 766; Header file 'C:\projects\temp.h' not
    used in module 'C:\projects\test.c'

    or

    0 Info 714; Symbol
    'eGetInternal_Extended(void)' (line 3988, file
    C:\projects\test.c) not referenced

    At this outputs I´m missing the file name and line number at beginn of the message. But there are known at the end of the messages.

    It´s hard to write a clean error parser, when the output messages changes.

    1 vote
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  9. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)

    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.

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

    uint32t mytime;
    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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  11. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  12. Add appended messages to the save/restore concept

    We are linting our complete software with different rulesets for its different SW-parts (because some are safety relevant and some are not, i.e. the rulesets differ, but the code analysis must check the software as a whole).

    Each SW-part's rulesets has its own active rules/errors + specific messages for the errors, which are added via the "-append()" option.
    In the course of action we use the save/restore options to get back to a basic common, global configuration.

    I.e. the complete command line is something like:

    lint-nt.exe

    <output file>

    <global base cfg>

    <msg output format cfg>.lnt

    (n-times) x [

    <SW-part specific

    3 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  13. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  14. Don't lock files during linting (windows, parallel builds)

    Lint open files on windows with file locking. This is the default method on windows. I suppose that lint uses fopen instead of OpenFile.
    This breaks the possibility to use parallel builds for speed up reasons on code that share some code base.
    Suggestion: Use OpenFile with OFSHAREDENYNONE to allow other lint instances and other programms to access that file. If you are worried about file deletion, use at least OFSHAREDENYWRITE.

    9 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  15. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
  • Don't see your idea?

General

Categories

Feedback and Knowledge Base