Technical Support FAQ
Go to FAQ Page 2
- How do I tell lint where to find my compiler headers?
- How do I tell lint not to complain about my compiler headers?
- How do I run PC-lint from inside my Microsoft Studio IDE?
- What is a library header?
- How do I suppress a message for a specific symbol? function? macro?
- I want to inhibit all messages emanating from one of my files, but the -efile option is not working.
- Help - I'm getting too many messages.
- I want to port from 32-bit to 64-bit code.
- What is strong type checking?
- How do I change the format of my lint messages?
- Will lint work with my cross-compiler?
- Lint complains about my in-line assembly.
- My lint error suppression is not working.
- Do you support any of the checks from Scott Meyers' books?
- Help - you don't have a compiler options file for my compiler.
- Can you tell me which of my #include files are not used?
- How can I torture test my code?
- What version of lint am I running?
- How do I get patches for PC-lint? for FlexeLint?
- How do I order an update?
Use the -i option or the INCLUDE
Environment Variable to designate a search path for files not found in the current
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
and +/-libh options. You can then use the
, -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 set up PC-lint as a tool. Follow the
instructions from the appropriate env-vc?.lnt file. The latest
files are available from Version 9.00 Patches
Lint uses the designation "library" for
those headers over which the programmer normally has no control -- such as compiler and
third-party headers. Use the options +libclass, +/-libdir,
and +/-libh to specify which headers are library. You can then use
the options -wlib, -elib, and -elibsym to
control lint messages emanating from "library headers", without affecting the
checking of your own code.
The -e# option will suppress all
instances of error message #
suppresses message # for symbol sym
) suppresses message # emanating from within function funcname
-emacro(#,macroname) suppresses message # within macro macroname
This option applies only to messages that are
parameterized on a filename (e.g. 7, 305, 306, 307, 314, 404,405, 406, 537,
766). This option will inhibit messages about a file, not
from within a file. To inhibit messages from within a
header file, see our discussion of "library".
If you get lots of messages from your compiler
headers, perhaps your configuration is not correct. If you're using a compiler that
we support with a co-*.lnt file, make sure you use it. If we don't
supply a file for your compiler, you may need to write your own. In general, use our
lint options to handle compiler extensions to the language - for instance, nullify
additional reserved words with the -d option or enable them with the +rw()option.
If you've never linted your code before, you may want
to modify the warning level initially. Try running with -w1 to
report only errors. After you've fixed the resulting errors (or suppressed those
that you don't want reported), run with -w2, and so forth.
Lint uses the size options (-s) to
specify the size of scalars for the target architecture. To see what your current
size settings are, run lint with a single argument equal to a ? and you
will receive a screen of all lint options and with current values for the size (-s)
options and the flag (+/-f...) settings. This works especially well
if you are using a batch file like lin.bat. If your command line is
"lin ?" then the value of size options and flags dumped will reflect the
options already set within std.lnt.
Although you may struggle hard to produce meaningful
typedef names for all your various int options the compiler will
generally ignore these names for type-checking purposes. Lint options
and -index will enable typedef-based type
checking. For a detailed discussion, see Strong Type Checking
Use the -format option. When
running lint from within an IDE or editor, it is often necessary to tailor the lint
message output to what is expected by your IDE or editor. The configuration files of
the form env-*.lnt will include the necessary format statement for the
most popular IDEs and editors. See section 5.6.3 of the manual for details.
The -width option specifies the
width of your output line.
The -h option specifies the height
of your error messages -- 1, 2, 3 or 4 lines.
Almost certainly. We've run into most of the
compiler peculiarities in our 26 years of serving the C and C++ community and have devised
ways and means of dealing with the vast majority of cases. Some of these methods are
described in our manual in section 5.8. For the more popular compilers we have
prepared compiler-option files whose names are of the form co-*.lnt.
First look for your compiler in the list of supported compilers shown in the Installation
script of the install program. If you don't see it there, you can look around for
one that will be close to yours. You can start by looking through
the latest files for Version 9.00 from our Version
9.00 Patches page. If you need some help feel
free to call our office and we will be happy to get you started.
The compiler writers have shown no shortage of
ingenuity in devising a wide range of schemes to incorporate in-line assembly within the
C/C++ code they support. First, make sure you're using the compiler options file we
supply with your compiler. If that doesn't take care of things check section 5.8 of
our manual and then check the read.me
file for any undocumented updates. If you
still have problems give our office a call. We have lots of experience helping
people with in-line assembly.
There could be many reasons for this. If you
run lint with the option -voif, you will receive information of every
option that lint processes and this may help track down the problem. Incidentally, a
neat way of doing this is by setting the LINT environment variable to -voif. Since
the environment variable is processed first it will display all your options, even those
within the batch file that you may be running from. Some of the common mistakes in
message suppression are:
- The option is incorrect. For example, you're
using -620, instead of -e620.
- Lint options are processed in order. Make
sure the names of your modules come after the appropriate error suppression files (.lnt)
- There is an ill-advised turn-off turn-on sequence
within the program. Any such sequence should be done with a save-restore.
example, the following sequence is good:
/*lint -save -e620 */
some code that would trigger a 620
/*lint -restore */
Whereas, the following sequence,
same code as before
/*lint +e620 */
is not good because it would interfere with an attempt to turn off message 620 from
the command line.
- You turn off a message, but inadvertently turn it back
on. Use -voif and then check your output to see which options are
- You're using lint comments within your source code but
they have no effect. Make sure to include the word 'lint' with no space before it.
- won't work
// lint -e620 - won't work
- You're trying to turn off a message with the wrong
option. For example, you use
to turn off message 744 for switch_one, but message 744 is
not parameterized by symbol, so you will need to do either a
to turn off the message globally, or you can put //lint !e744
into your source code for one line error suppression of this message. Also don't
forget the handy -efunc(744,f) option.
Although most of the Scott Meyers checks are enabled
by default, some have been placed in the Elective Note category. Choose the appropriate
au-sm*.lnt configuration file to
enable the Scott Meyers checks.
We will be happy to work with you to devise one for
your compiler. Start with one of the existing compiler options files and see how far
you get. If you're using Windows, the install program should have
copied all the lnt files into subdirectory
\lnt within your lint installation directory. To
access the compiler options files from the distribution CD, look in the
subdirectory \DOS-ins\lnt . You can also download
the most current .lnt files from Version 9.00 Patches.
To see just your header anomalies (and turn off all
other messages), use the options
-w1 +e749 +e?75? +e?76? +e964 +e966
Use the following options:
+fsc assumes string
constants are const char*
+fpn warns about the
use of pointer parameters without first checking for NULL
typedefs must match exactly
-w4 use the maximum
Run lint with the -v option (to keep it from
outputting a help screen) and look at the banner line. It will say something
PC-lint for C/C++ (NT) Ver. 9.00a
which means you're running the PC-lint Windows executable version 9.00 and patch level a.
PC-lint 9.00 patches are available from our
Version 9.00 patch web
page. FlexeLint 9.00 patches are also posted, but the program
to apply the patches must be requested from us - please make sure to include your
FlexeLint serial number (if you know it) and your company name and address. You can
phone us at (610) 584-4261, or send email to
"sales" at gimpel.com (Note: We can provide you with
the FlexeLint patch program only if we have your signed FlexeLint agreement on file.)
Go to FAQ Page 2
If you're already in our database (purchased your
lint directly from us, or returned your registration card to us, you can order by phone with a
VISA, MC or AMEX. If you're not in our
database, we will also need a photocopy of your distribution diskette showing the
serial number. You will receive your update with the same serial number.
Ordering details can be found at order.htm
Home | Contact
PC-lint Plus, PC-lint and FlexeLint are trademarks of Gimpel Software LLC
Copyright © 2018, Gimpel Software LLC, All rights reserved.