PC-lint Plus Support
Built for coders, shaped by you.
PC-lint Plus is designed to make your life easier. Share your ideas for improvements using the button below, or vote on existing suggestions. Have general feedback? Use the feedback button to let us know.
Customer Requests for PC-lint Plus
| All | Created |
|---|---|
| Add metric to find commented-out code <p>Add metric to find commented-out code.</p> XPlanned |
Add metric to find commented-out codeAdd metric to find commented-out code Planned 3VotesVote Now! |
| Option for output in "Serif" format <p>A couple of customers have asked for results in the "serif" format as specified at <a href="https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.pdf">https://docs.oasis-open.org/sarif/sarif/v2.1.0/sarif-v2.1.0.pdf</a>. 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.</p> XPending |
Option for output in "Serif" formatAdd an option to export results in SARIF format. Pending 5VotesVote Now! |
| Reinstate detection of unused headers <p>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?</p> XPending |
Reinstate detection of unused headersAdd detection of unused headers. Pending 5VotesVote Now! |
| Value tracking arrives at incorrect conclusion when incrementing variables in loop conditions <p>Consider the following program:</p> <pre><code class="language-plaintext"> #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; }</code></pre> <p>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:</p> <pre><code class="language-plaintext"> 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)</code></pre> <p>I suspect Lint is confusing `val++` for `++val` which would make the warning correct.</p> XPending |
Value tracking arrives at incorrect conclusion when incrementing variables in loop conditionsNeed fix for PC-lint Plus value tracking, incorrect warning found. Pending 1VotesVote Now! |
| Value tracking simultaneously assumes enums both can and cannot take any value <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <pre><code class="language-plaintext"> #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; }</code></pre> XPending |
Value tracking simultaneously assumes enums both can and cannot take any valueClarification needed on enumerated values Pending 1VotesVote Now! |
| Relaxed parsing of *-e* inhibitions for multiple messages <p>'Compare the parser requirement for separating commas </p> <pre><code class="language-plaintext">[#... -ecall(# [# ...], Function [,Function ...]) -emacro(# [# ...], Symbol [,Symbol ...]) -estring(# [# ...], String [,String ...]) -esym(# [# ...], Symbol [,Symbol ...]) -etype(# [# ...], Type [,Type ...])</code></pre> <p>...vs. </p> <pre><code class="language-plaintext">[,#... -e(# [,# ...]) --e(# [,# ...]) -e{# [,# ...]} --e{# [,# ...]}</code></pre> <p>...which in my opinion makes usage a bit more difficult than necessary, as the two groups of inhibitions have slightly different requirements.</p> <p>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.</p> <pre><code class="language-plaintext">-e(# [[,]# ...]) --e(# [[,]# ...]) -e{# [[,]# ...]} --e{# [[,]# ...]}</code></pre> <p>In the long run, this could even be simplified to...</p> <pre><code class="language-plaintext">-e(# [# ...]) --e(# [# ...]) -e{# [# ...]} --e{# [# ...]}</code></pre> <p>...finally resulting in the same syntax as the first group.</p> XPending |
Relaxed parsing of *-e* inhibitions for multiple messagesRelax the parsing of *-e* inhibitions for multiple messages Pending 1VotesVote Now! |
| Default the pure ANSI/ISO C standard functions to -sem(..., pure) <p>'Several messages (e.g. 523 and 9007) deal with potential side-effects. This is great, but the implementation has room for improvement:</p> <p>if ((s != NULL) && ((strlen(s) > 0U)))</p> <p>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.</p> <p>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).</p> <p>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:</p> <p>-sem(isalnum, pure) // <ctype.h><br />-sem(isalpha, pure) // <ctype.h><br />-sem(isblank, pure) // <ctype.h><br />-sem(iscntrl, pure) // <ctype.h><br />-sem(isdigit, pure) // <ctype.h><br />-sem(isgraph, pure) // <ctype.h><br />-sem(islower, pure) // <ctype.h><br />-sem(isprint, pure) // <ctype.h><br />-sem(ispunct, pure) // <ctype.h><br />-sem(isspace, pure) // <ctype.h><br />-sem(isupper, pure) // <ctype.h><br />-sem(isxdigit, pure) // <ctype.h><br />-sem(toupper, pure) // <ctype.h><br />-sem(tolower, pure) // <ctype.h><br />-sem(memchr, pure) // <string.h><br />-sem(memcmp, pure) // <string.h><br />-sem(strcat, pure) // <string.h><br />-sem(strcat_s, pure) // <string.h><br />-sem(strncat, pure) // <string.h><br />-sem(strncat_s, pure) // <string.h><br />-sem(strchr, pure) // <string.h><br />-sem(strrchr, pure) // <string.h><br />-sem(strcmp, pure) // <string.h><br />-sem(strncmp, pure) // <string.h><br />-sem(strcoll, pure) // <string.h><br />-sem(strcoll_l, pure) // <string.h><br />-sem(strcpy, pure) // <string.h><br />-sem(strcpy_s, pure) // <string.h><br />-sem(strncpy, pure) // <string.h><br />-sem(strncpy_s, pure) // <string.h><br />-sem(strerror, pure) // <string.h><br />-sem(strlen, pure) // <string.h><br />-sem(strnlen, pure) // <string.h><br />-sem(strspn, pure) // <string.h><br />-sem(strcspn, pure) // <string.h><br />-sem(strstr, pure) // <string.h><br />-sem(strtok, pure) // <string.h><br />-sem(strxfrm, pure) // <string.h><br />-sem(abs, pure) // <stdlib.h><br />-sem(labs, pure) // <stdlib.h><br />-sem(llabs, pure) // <stdlib.h><br />-sem(fabs, pure) // <stdlib.h>, <math.h><br />-sem(fabsf, pure) // <stdlib.h><br />-sem(fabsl, pure) // <stdlib.h><br />-sem(div, pure) // <stdlib.h><br />-sem(ldiv, pure) // <stdlib.h><br />-sem(lldiv, pure) // <stdlib.h><br />-sem(acos, pure) // <math.h><br />-sem(asin, pure) // <math.h><br />-sem(atan, pure) // <math.h><br />-sem(atan2, pure) // <math.h><br />-sem(ceil, pure) // <math.h><br />-sem(cos, pure) // <math.h><br />-sem(cosh, pure) // <math.h><br />-sem(exp, pure) // <math.h><br />-sem(floor, pure) // <math.h><br />-sem(fmod, pure) // <math.h><br />-sem(fpclassify, pure) // <math.h><br />-sem(frexp, pure) // <math.h><br />-sem(frexpf, pure) // <math.h><br />-sem(isfinite, pure) // <math.h><br />-sem(isinf, pure) // <math.h><br />-sem(isnan, pure) // <math.h><br />-sem(isnormal, pure) // <math.h><br />-sem(ldexp, pure) // <math.h><br />-sem(log, pure) // <math.h><br />-sem(modf, pure) // <math.h><br />-sem(pow, pure) // <math.h><br />-sem(signbit, pure) // <math.h><br />-sem(sin, pure) // <math.h><br />-sem(sinh, pure) // <math.h><br />-sem(sqrt, pure) // <math.h><br />-sem(tan, pure) // <math.h><br />-sem(tanh, pure) // <math.h></p> <p>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.</p> XPlanned |
Default the pure ANSI/ISO C standard functions to -sem(..., pure)PC-lint Plus should default all ANSI/ISO C standard functions that are known to be pure to -sem(..., pure) Planned 2VotesVote Now! |
| Support caching of analyses (something similar to ccache) <p>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.</p> <p>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.</p> XPlanned |
Support caching of analyses (something similar to ccache)Need faster times in analyzing larger files Planned 6VotesVote Now! |
| Support ARM compiler v6 for Keil <p>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.</p> <p>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.</p> XPending |
Support ARM compiler v6 for KeilThe PC-Lint Plus Configurator currently supports ARM compiler v5 for Keil. ARM v6 has been supported by Keil for some time, it would be useful if the configurator did as well. Pending 6VotesVote Now! |
| Enable opt-in assumptions about the initial values of static variables <p>This condition doesn't seem to be detected by PC-lint Plus:</p> <pre><code class="language-plaintext">#include <stdint.h> #include <string.h> typedef struct { uint8_t one; uint8_t two; uint8_t three[18]; } test_t; static test_t *mp_def; static test_t *mp_abc; void test (void) { // These manipulations should trigger a warning since both pointers are not initialized. mp_def->one = 1; mp_abc->one = 2; }</code></pre> XPending |
Enable opt-in assumptions about the initial values of static variablesPending 1VotesVote Now! |
| Improve support for AUTOSAR <p>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.</p> <p>Please improve the number of supported AUTOSAR rules.</p> XStarted |
Improve support for AUTOSARPlease improve the number of supported AUTOSAR rules. Started 21VotesVote Now! |
| Consider adding reporting capabilities to PC-LINT Plus <p>Most competing tools can generate MISRA compliance reports at the push of a button.<br />With PC-LINT 9.0L it is a rather tedious procedure, e.g. running with ++efreeze, parsing text output and generating a result.</p> XPending |
Consider adding reporting capabilities to PC-LINT PlusMost 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. Pending 19VotesVote Now! |
| Add option to show messages found in header file only once <p>Consider this: a.h contains 10 problems and is included in 10 modules.<br />That leaves you with 100 lint messages in the log, when in reality there are only 10 problems to fix.<br />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). </p> XPlanned |
Add option to show messages found in header file only onceHaving 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) Planned 29VotesVote Now! |
| Add an option to identify undefined behavior <p>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.</p> <p>Even though not all kinds of UB can be detected by a static analysis tool, many are, and other tools do this pretty well.</p> <p>Piggy-backing onto this -- would also be nice to identify implementation-defined behaviors (e.g. bit position of bit-fields) and unspecified behaviors.</p> <p>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.</p> XPending |
Add an option to identify undefined behaviorImprove detection of undefined behavior in static analysis Pending 19VotesVote Now! |
| Preprocessor output for a specific code section <p>The "-p run just the Preprocessor" option is very handy, but for me it often generates too much information to pour though when I'm trying to diagnose a specific macro issue.</p> <p>It would be great if the preprocessor output could be enabled for a section of code, and send the output to a file and/or standard out.</p> <p>e.g.:</p> <p><br />//lint -p+<br />SOME_COMPLEX_MACRO(a,b,c,d,e);<br />//lint -p-<br /> </p> XPending |
Preprocessor output for a specific code sectionIt would be great if the preprocessor output could be enabled for a section of code and send the output to a file and/or standard out. Pending 4VotesVote Now! |
| Display all options currently in effect (What Options am I using here) <p>Although "-vo" and "lint usual arguments ?" are useful, they produce a lot of information, including information that sometimes could be considered 'what was noise' such as temporary error suppressions "-save, -e123, -restore"</p> <p>It would be great if you could add a feature where I could display all options, suppressions, flags, etc. in effect at a specific point in a source file that have been:<br />a) changed from the defaults, or<br />b) changed since the last "-save"<br />c) changed in this file</p> <p>for example:</p> <pre><code class="language-plaintext"> //lint -save //lint -e123 //lint -esym(456, FooBar) ... /*lint -save -e789 */ MACRO /*lint -restore */ ... int foo() { //lint -ListOptions(save) }</code></pre> <p><br />would tell me about -e123 and -esym(456, FooBar) but not -e456<br /> </p> XPlanned |
Display all options currently in effect (What Options am I using here)It would be great if you could add a feature where I could display all options, suppressions, flags, etc. in effect at a specific point in a source file that have been changed Planned 10VotesVote Now! |
| Use a fixed release cycle <p>Customers could plan better, if they knew you have 2 or 4 releases per year.<br />Right now it´s totally unpredictable.</p> XPlanned |
Use a fixed release cycleCustomers could plan better, if they knew you have 2 or 4 releases per year. Planned 10VotesVote Now! |
| Add support for pthread_mutex_trylock() semantics <p>As described in <a href="http://www.gimpel.com/Discussion.cfm?ThreadID=3793">http://www.gimpel.com/Discussion.cfm?ThreadID=3793</a> this functionality is needed.</p> <p>For example, this function results in lint warning 455 (A thread mutex that had not been locked is being unlocked):</p> <pre><code class="language-plaintext"> bool IsLocked() { int retStat = pthread_mutex_trylock(&m_pthreadMutex); if (retStat == 0) { // Mutex was not locked, but is now. pthread_mutex_unlock(&m_pthreadMutex); return (false); } else if (retStat == EBUSY) { // Mutex is already locked. return (true); } return (false); } </code></pre> XPending |
Add support for pthread_mutex_trylock() semanticsNeed support for pthread_mutex_trylock() semantics Pending 17VotesVote Now! |
| Allow Lint to see that constructor takes ownership of memory. <p>Lint sees that ownership of allocated memory is taken by a constructor if the owning object isn't "new'd". But if the owning object is "new'd", then Lint does not understand this. See the example below, which works in the online demo.</p> <p>This was discussed in this thread, as well as several others:<br /><a href="http://www.gimpel.com/Discussion.cfm?ThreadID=808">http://www.gimpel.com/Discussion.cfm?ThreadID=808</a></p> <pre><code class="language-plaintext"> //lint -e438, -e529, -e1502, -e1712, -e1788, -e714 #include <memory> struct A { A(char *){}; }; void g( ) { // This results in a 429 warning. char * ptr1 = (char *) malloc(10); A *a1 = new A(ptr1); // This does not result in a 429 warning. char * ptr2 = (char *) malloc(10); A a2(ptr2); } </code></pre> XPlanned |
Allow Lint to see that constructor takes ownership of memory.Lint sees that ownership of allocated memory is taken by a constructor if the owning object isn't "new'd". But if the owning object is "new'd", then Lint does not understand this. See the example here, which works in the online demo. Planned 16VotesVote Now! |
| Detect -e Options and -save without -restore <p>'-e Options without surrounding -save/-restore in the same file shall be warned.<br />Also a -save without -restore in the same file or same block level shall be warned.</p> <p><strong>PC-lint Plus Update: </strong>In PC-lint Plus, suppression options inside a source module do not “leak” to subsequent modules so this is less of an issue for PC-lint Plus than it was for PC-lint but we do plan to add a warning for -save options that do not have corresponding -restore options in a future update to PC-lint Plus.</p> XPlanned |
Detect -e Options and -save without -restoreUpdate: In PC-lint Plus, suppression options inside a source module do not “leak” to subsequent modules so this is less of an issue for PC-lint Plus than it was for PC-lint but we do plan to add a warning for -save options that do not have corresponding -restore options in a future update to PC-lint Plus Planned 16VotesVote Now! |
| Out Of Bounds Checking at Start Of Array <p>This is 'out-of-bounds' is detected:</p> <pre><code class="language-plaintext"> unsigned char buffer[5]; unsigned char* buffer_ptr = &buffer[4]; ++buffer_ptr; // ERROR! now points to 1 byte after &buffer[4] *buffer_ptr = 0x12; // assign to memory outside of buffer[]</code></pre> <p><br />This 'out-of-bounds' is NOT detected:</p> <pre><code class="language-plaintext"> unsigned char buffer[5]; unsigned char* buffer_ptr = &buffer[0]; --buffer_ptr; // ERROR! now points to 1 byte before &buffer[0] *buffer_ptr = 0x12; // assign to memory outside of buffer[]</code></pre> <p>As 'buffer_ptr' has been 'bound' to 'buffer' via the assignment I would have expected PC-lint to have detected this.</p> XPending |
Out Of Bounds Checking at Start Of Array'Out-of-Bounds' is not detected by PC-lint Plus Pending 5VotesVote Now! |
| Add a new warning to find use of an explicit cast from real to unsigned int. <p>Although an explicit cast looks like the programmer knew, the intended behavior may need two casts.</p> <p><br />I wanted to "infinitely" accumulate possibly small, possibly negative increments (float i) in a modulo counter consisting of an unsigned integer variable (uint32_t n) and a real variable (float f) for the fractional part.</p> <pre><code class="language-plaintext">f += i; n += (uint32_t)f; // should read n += (uint32_t)(int32_t)f; f -= (int32_t)f;</code></pre> <p>worked with several compilers for PC platforms (gcc, lcc32, VS C++) and with TI''s c6000 compiler for an OMAP L138, but the counter failed to decrease with TI's ARM5.1 compiler for the 7R4 core.</p> <p>This is implementation defined behavior as of C99 6.3.1.4, but none of the compilers emitted a warning nor does lint.<br /> </p> XPending |
Add a new warning to find use of an explicit cast from real to unsigned int.Pending 4VotesVote Now! |
| Be able to suppress for derived classes <p>Sometimes it would be nice to suppress a message for all derived classes.</p> <p>For example:</p> <pre><code class="language-plaintext">class X { virtual void f() = 0; }; class Y : public X { void f() {} }; class Z : public X { int i; void f(){++i;} };</code></pre> <p>I would like to be able to put the following comment with the declaration of X:<br />//lint -esym(1961,[X]::f) //1961 - virtual member function 'Symbol' could be made const</p> <p>Where I use [X] as syntax to define X and all classes derived from it.<br />So when a sub class dos not use the function f to the full extend lint knows from the comments that came with X</p> <p>Also for other messages it would be nice to inhibit it for a family of classes.</p> XPending |
Be able to suppress for derived classesHave an option to suppress a message for all derived classes Pending 5VotesVote Now! |
| Find message inhibitions inside files that have no effect <p>Sometimes the following happens: <br /> </p> <p>Code is created with a deliberate violation of a lint message.<br />The message in inhibited with a comment in the code.<br />However, it often happens comments are not updated with code. <br />So, the reason for the inhibition may be removed and the inhibition stays.</p> <p>It would be nice to find such "broken" inhibitions, (that have no effect on the resulting messages even when all other inhibitions are disabled). <br />Maybe this search can be a result of executing pc-lint with a special flag.</p> <p>This way the code can be cleaned of old inhibitions.</p> XStarted |
Find message inhibitions inside files that have no effectClean code of old inhibitions Started 47VotesVote Now! |
Have a New Idea?
Share it using the button below or vote for suggestions that matter to you. Your input makes a difference!
PC-lint Plus Manual
Need more details? Explore the full PC-lint Plus Manual for in-depth guidance and best practices.