3

I'm using Gimpel's PC-Lint v8.00 on a C codebase and am looking to understand how it traverses modules. The PC-lint manual only goes as far as to say that PC-Lint "looks across multiple modules". How does it do this? For example, does it start with one module and combine all related include files and source files into one large piece of code to analyze? How deep does it search in order to understand the program flow?

In a second related question, I have a use case where it is beneficial for me to lint one C module from the codebase at a time instead of providing every C module in a long list to PC-Lint. However, if I only provide one C module, will it automatically find the other C modules which it depends on, and use those to understand the program flow of the specified C module?

Blue
  • 820
  • 4
  • 17
alphaOri
  • 87
  • 3
  • 6

2 Answers2

3

PC Lint creates some sort of run-time database when it parses your source files, noting things like global variables, extern-declarations, etc. When it has processed all compilation units (C files with all included files, recursively), it does what a linker does to generate your output, but in stead of generating code, it reports on certain types of errors, for instance: An extern-declaration that has not been used, an unused prototype without implementation, unused global functions. These are issues not always reported by the linker, since the code generation is very well possible: The items have never been used anywhere!

The search depth can be influenced by the option -passes, which enables a far better value-tracking at the cost of execution time. Refer to seciton 10.2.2.4 in the PDF manual (for version 9.x).

To your second question, no, if you only provide one (or a few) source (C) file name(s) on your Lint command line, PC Lint will process only that file - and all include files used, recursively. You may want to use the option -u for "unit-checkout" to tell PC Lint that it only processes a part of a full project. Lint will then suppress certain kinds of warnings not useful for a partial project.

Johan Bezem
  • 2,582
  • 1
  • 20
  • 47
  • Thanks. Could you elaborate on the order in which the compilation units are recursively processed. Will PC-Lint proceed to each included file until it can do so not longer, then process its way back up? Another way to say this is in terms of a tree. Will lint create the tree then process each file starting from the leaves of the tree and working its way back to the root. An example would be if I have a c file which includes x1.h which, in turn, includes x2.h and x3.h. I would expect lint to process x2.h, x3.h, x1.h, and lastly the cfile. Is this correct? – alphaOri Nov 26 '12 at 14:36
  • 1
    Every C file is processed like a compiler would. For each compilation unit, Lint looks at the header files included, processes them, and if they include further header files it processes them, etc. Therefore, recursively. The C files are processed one after the other, until all have been processed. So in your example, it would start reading the C file, and when x1.h is included it would process x1.h until x2.h is included, etc. After all included files have been processed, it would process the remaining part of the C file and finish. – Johan Bezem Nov 27 '12 at 05:09
  • Ok. From what I see in my output, if two source files include the same header file, that header file is analyzed once for each source file and thus its messages are repeated. I think this adds unnecessary clutter to my output file. Is there a good reason that PC-Lint does this? Is there a way to tell PC-Lint to remember previously linted header files and ignore them if encountered again? – alphaOri Nov 28 '12 at 09:42
  • Basically not, since Lint legitimately assumes that a header warning for one compilation unit may not be warranted for a different compilation unit (e.g. if you do not use the macro it complained about before. However, you may take a look if you can use pre-compiled headers and/or bypass headers in chapter 7 of the PC Lint 9.0 manual. It will also illustrate some of the reasons why repeated processing may be necessary in several cases. – Johan Bezem Nov 28 '12 at 10:30
1

I think in principle you're asking about LINT OBJECT MODULES, see Chapter 9 of Lint Manual PDF. Using say lint -u a1.c -oo procudes the a1.lob, when then again can be linked together using lint *.lob to produce the inter-module messages.

Also you asked a related, specific questions ( Any tips for speeding up static analysis tool PC-Lint? Any experiences using .LOB files?) but I'm not sure if I understand your concern with "How much would you say it affected linting time?", because I would say it depends. What is your current lint-time / speed? You posted some years ago now, how about running the job on a novel machine, new cpu then? KR

Community
  • 1
  • 1