Using PC-Lint on project with third party libraries
Asked Answered
B

1

7

I have a project which includes a large third party library and am required to ensure that the project is lint-free. However, the library has several thousand errors.

Modifying the library to remove these is not an option - how would this typically be handled?

Currently, the code is built using Keil uVision and this is where PC-Lint is called from so if this could still be the case that would be best.

Is there a way to specify that these are library files and so should not be analysed?

Thanks.

Brahe answered 26/5, 2013 at 21:12 Comment(2)
So you're looking for a way to just completely skip linting a set of source files? (Your library isn't a pre-compiled object file, you're compiling from source?) If you completely skip the files, you may end up with "function not defined" type errors during the global wrap-up...Hermann
Exactly. This is why I do not just exclude the files from the LINT command. Is it possible to include them for this purpose, but also to indicate that their errors should be omitted?Brahe
T
8

Here is the info from the Gimpel website, I believe that it covers the options you are looking for (bold added for emphasis):

Lint uses the label of "library" header to designate those headers over which a programmer has no control (such as compiler headers). By default all #includes from a foreign directory, or enclosed within < > , are considered "library." This can be modified through the use of the +libclass option, and further fine-tuned with the +/-libdir and +/-libh options. You can then use the -wlib , -elib and -elibsym options to control just those messages being emitted from library headers. Compiler options files distributed with PC-lint usually contain a -wlib(1) option which limits lint output from library headers to errors only (suppressing warning and informational messages).

You can find more information at the Gimpel site here.

Also, if I remember correctly, -wlib(0) suppresses all library errors and warnings... as opposed to the -wlib(1) mentioned above. I will have to double check when I get back to work. I don't have a copy of the manual with me.

---EDIT---

If it is an option, I would place all of the files associated with the library in a different directory. In Keil, you can go to "Tools->Set-up PC-Lint". Then add your new directory to the list of "PC-Lint Include Folders". Your -wlib(0) option should then treat those headers as 'foreign' and not return errors. Of course, you would have to modify the project settings to compile the library files as well.

---EDIT2 Added Example---

Okay, so here is a little test I tried to ensure that my suggestion would work. I created a project in a directory I named "ex_lib" and named the project lib_test. In "Source Group 1" I created and added the file "main.c":

main.c

#include <lib_test.h>

int main (void)
{
    uint16_t x = 5;
    uint16_t y = 10;
    uint16_t total1 = 0;
    uint16_t total2 = 0;
    uint16_t total3 = 0;
    uint16_t total4 = 0;


    total1 = add(x,y);
    total2 = sub(x,y);
    total3 = mult(x,y);
    total4 = div(x,y);

    return 0;
}

I then created a sub-directory named "library" and created a second project named library in that directory. The library project consisted of the following files "lib_test.h" and "lib_test.c".

lib_test.h

#ifndef LIB_TEST__
#define LIB_TEST__

#include <stdint.h>

extern uint16_t add(uint16_t x, uint16_t y);
extern uint16_t sub(uint16_t x, uint16_t y);
extern uint16_t mult(uint16_t x, uint16_t y);
extern uint16_t div(uint16_t x, uint16_t y);

#endif /* LIB_TEST__ */

lib_test.c

#include "lib_test.h"

uint16_t add(uint16_t x, uint16_t y)
{
    return (x + y);
}

uint16_t sub(uint16_t x, uint16_t y)
{
    return (x - y);
}

uint16_t mult(uint16_t x, uint16_t y)
{
    return (x * y);
}

uint16_t div(uint16_t x, uint16_t y)
{
    return (x / y);
}

In the library project, under "Options for Target 'Target 1'", I selected "Create Library". I then compiled the library project.

After successfully compiling, I went back to the lib_test project and right-clicked on "Target1" and selected "Add Group". I created a group called "Library" and added the previously compiled "library.lib" from the "library" directory to the "Library" group.

Finally, under the options for Target 1 (in the lib_test project), I went to the "C/C++" tab and added "library" to the "Include Paths". I was then able to successfully compile (with some warnings about variables being set but never used) the lib_test project. Under "Tools->Set-up PC-Lint" I added the following:

PC-Lint Include Folders: C:\Keil_ARM\RV31\INC\ and library\

Lint Executable: C:\Lint\LINT-NT.EXE

Configuration File: C:\Lint\lnt\CO-RV.LNT

I modified the CO-RV.LNT file to verify my Lint results by modifying -wlib(). When I ran Lint with -wlib(0) I received no warnings or errors about my library files. I then changed -wlib(2) and I received numerous warnings about stdint.h.

This is definitely an oversimplification but it should give you a good starting point. Also, I received Lint warnings about my variables not being accessed in "main.c" but I expected that.

Truda answered 26/5, 2013 at 22:36 Comment(7)
I did see this and have tried it - but as far as I can see, it an only be applied to header files - is this wrong?Brahe
I think the key is to ensure that your third party library files are in a 'foreign' directory - then all #includes to their header files would reference that directory. It may be a bit too cumbersome depending on the size of your project, but it is an option.Truda
Wow, thanks for the detailed response! I already have all the library files in a dedicated directory. Separating into two projects and using the library file could work, but this breaks the 'Go To Definition Of ..' feature, which is a shame. My concern for completely skipping the files is that I believe a complete project analysis is best (both for use with ALOA and to avoid 'function not defined' errors - so all in all, I would like to keep everything together so that Keil functionality is not broken, but indicate that certain files may contain errors. Is this possible?Brahe
I can see how that would be an issue. One option may be to lint the library separately. You shouldn't have any "function not defined" errors with the method above. I actually use SlickEdit for my code editor because I am often working with different tools/compilers (uVision, VisualDSP++, MPLAB, etc). So I run PC-Lint and do all of my editing through SlickEdit and handle compiling/debugging dependent upon the platform I am working on. I am sure that there is a work-around, but you would probably have to play around to get it to work.Truda
Add: use -e686 option after -wlib(0) to remove warning: Option 'wlib(0)' is suspicious because of ...Periodical
@Periodical I found that I needed to use -e686 before -wlib(0) to suppress the error message. I had -wlib(0) in a .lnt file, so I needed to place -e686 either at the top of the .lnt file, or on the commandline before the .lnt file is passed. Adding -e686 to a second .lnt file listed after the first didn't work. Thanks for the lead though! I used this to avoid 686 from messing up my XML output that I feed to SonarQube.Cutlerr
@Cutlerr Thanks to pointing out this, you are right, -e686 should be before -wlib(0). Struggling with flexelint for SonarQube also led me here :)Periodical

© 2022 - 2024 — McMap. All rights reserved.