IPnom Home • Manuals • FreeBSD

 FreeBSD Man Pages

Man Sections:Commands (1)System Calls (2)Library Functions (3)Device Drivers (4)File Formats (5)Miscellaneous (7)System Utilities (8)
Keyword Live Search (10 results max):
 Type in part of a command in the search box.


lint -- a C program verifier


     lint [-abceghprvwxzHFV] [-s | -t] [-i | -nu] [-D name[=def]] [-U name]
	  [-I directory] [-d directory] [-L directory] [-l library]
	  [-o outputfile] [-B directory] [-X id[,id ...]] file ...
     lint [-abceghprvwzHFV] [-s | -t] -C library [-D name[=def]] [-U name]
	  [-I directory] [-d directory] [-B directory] [-X id[,id ...]]
	  file ...


     The lint utility attempts to detect features of the named C program files
     that are likely to be bugs, to be non-portable, or to be wasteful.  It
     also performs stricter type checking than does the C compiler.  The lint
     utility runs the C preprocessor as its first phase, with the preprocessor
     symbol ``lint'' defined to allow certain questionable code to be altered
     or skipped by lint.  Therefore, this symbol should be thought of as a
     reserved word for all code that is to be checked by lint.

     Among the possible problems that are currently noted are unreachable
     statements, loops not entered at the top, variables declared and not
     used, and logical expressions with constant values.  Function calls are
     checked for inconsistencies, such as calls to functions that return val-
     ues in some places and not in others, functions called with varying num-
     bers of arguments, function calls that pass arguments of a type other
     than the type the function expects to receive, functions whose values are
     not used, and calls to functions not returning values that use the non-
     existent return value of the function.

     Filename arguments ending with .c are taken to be C source files.	File-
     name arguments with names ending with .ln are taken to be the result of
     an earlier invocation of lint, with either the -i, -o, or -C option in
     effect.  The .ln files are analogous to the .o (object) files produced by
     cc(1) from .c files.  The lint utility also accepts special libraries
     specified with the -l option, which contain definitions of library rou-
     tines and variables.

     The lint utility takes all the .c, .ln, and llib-llibrary.ln (lint
     library) files and processes them in command-line order.  By default,
     lint appends the standard C lint library (llib-lc.ln) to the end of the
     list of files.  When the -i option is used, the .ln files are ignored.
     Also, when the -o or -i options are used, the llib-llibrary.ln files are
     ignored.  When the -i option is omitted the second pass of lint checks
     this list of files for mutual compatibility.  At this point, if a com-
     plaint stems not from a given source file, but from one of its included
     files, the source filename will be printed followed by a question mark.

     The special input file name ``-'' causes lint to take input from standard
     input (until end of file) and process it as if it were a .c file.	If the
     -i flag is given and ``-'' is named as one of the input files, the -o
     flag must also be specified to provide an output file name.  The options
     are as follows:

     -a      Report assignments of long values to variables that are not long.

     -aa     Additional to -a, report all assignments of integer values to
     -e      Complain about unusual operations on enum-Types and combinations
	     of enum- and integer-Types.

     -g      Don't print warnings for some extensions of gcc(1) to the C lan-
	     guage.  Currently these are nonconstant initializers in automatic
	     aggregate initializations, arithmetic on pointer to void, trail-
	     ing commas in enum declarations, C++ -style ``//'' comments, zero
	     sized structures, subscripting of non-lvalue arrays, prototypes
	     overriding old style function declarations and long long integer
	     types.  The -g flag also turns on the keywords asm and inline
	     (alternative keywords with leading underscores for both asm and
	     inline are always available).

     -h      Apply a number of heuristic tests to attempt to intuit bugs,
	     improve style, and reduce waste.

     -i      Produce a .ln file for every .c file on the command line.	These
	     .ln files are the product of lint's first pass only, and are not
	     checked for compatibility between functions.

     -n      Do not check compatibility against the standard library.

     -p      Attempt to check portability of code to other dialects of C.

     -r      In case of redeclarations report the position of the previous

     -s      Strict ANSI C mode.  Issue warnings and errors required by ANSI
	     C.  Also do not produce warnings for constructs which behave dif-
	     ferently in traditional C and ANSI C.  With the -s flag,
	     __STRICT_ANSI__ is a predefined preprocessor macro.

     -t      Traditional C mode.  __STDC__ is not predefined in this mode.
	     Warnings are printed for constructs not allowed in traditional C.
	     Warnings for constructs which behave differently in traditional C
	     and ANSI C are suppressed.  Preprocessor macros describing the
	     machine type (e.g., sun3) and machine architecture (e.g., m68k)
	     are defined without leading and trailing underscores.  The key-
	     words const, volatile and signed are not available in traditional
	     C mode (although the alternative keywords with leading under-
	     scores still are).

     -u      Do not complain about functions and external variables used and
	     not defined, or defined and not used (this is suitable for run-
	     ning lint on a subset of files comprising part of a larger pro-

     -v      Suppress complaints about unused arguments in functions.

     -x      Report variables referred to by extern declarations, but never

     -z      Do not complain about structures that are never defined (for
	     example, using a structure pointer without knowing its contents).

     -B path
	     Path to use when looking for the lint1 and lint2 binaries.
	     Defaults to /usr/libexec.

     -D name[=def]
	     Define name for cpp(1), as if by a #define directive.  If no def-
	     inition is given, name is defined as 1.

     -I directory
	     Add directory to the list of directories in which to search for
	     include files.

     -d directory
	     Use directory instead of /usr/include as the default place to
	     find include files.

     -l library
	     Include the lint library llib-llibrary.ln.

     -L directory
	     Search for lint libraries in directory and directory/lint before
	     searching the standard place.

     -F      Print pathnames of files.	The lint utility normally prints the
	     filename without the path.

     -H      If a complaint stems from an included file lint prints the name
	     of the included file instead of the source file name followed by
	     a question mark.

     -o outputfile
	     Name the output file outputfile.  The output file produced is the
	     input that is given to lint's second pass.  The -o option simply
	     saves this file in the named output file.	If the -i option is
	     also used the files are not checked for compatibility.  To pro-
	     duce a llib-llibrary.ln without extraneous messages, use of the
	     -u option is suggested.  The -v option is useful if the source
	     file(s) for the lint library are just external interfaces.

     -U name
	     Remove any initial definition of name for the preprocessor.

     -V      Print the command lines constructed by the controller program to
	     run the C preprocessor and lint's first and second pass.

     -w      Treat warnings as errors.

     -X id[,id ...]
	     Suppress error messages identified by the list of ids.  A list of
	     messages and ids can be found in lint(7).

   Input Grammar
     lint's first pass reads standard C source files.  The lint utility recog-
     nizes the following C comments as commands.

     /* ARGSUSEDn */
	     makes lint check only the first n arguments for usage; a missing
	     n is taken to be 0 (this option acts like the -v option for the
	     next function).

     /* FALLTHRU */ or /* FALLTHROUGH */
	     suppress complaints about fall through to a case or default
	     labelled statement.  This directive should be placed immediately
	     preceding the label.

     /* LINTLIBRARY */
	     At the beginning of a file, mark all functions and variables
	     defined in this file as used.  Also shut off complaints about
	     unused function arguments.

     /* LINTED [comment] */ or /* NOSTRICT [comment] */
	     Suppresses any intra-file warning except those dealing with
	     unused variables or functions.  This directive should be placed
	     on the line immediately preceding where the lint warning

     /* LONGLONG */
	     Suppress complaints about use of long long integer types.

     /* NOTREACHED */
	     At appropriate points, inhibit complaints about unreachable code.
	     (This comment is typically placed just after calls to functions
	     like exit(3)).

     /* PRINTFLIKEn */
	     makes lint check the first (n-1) arguments as usual.  The n-th
	     argument is interpreted as a printf(3) format string that is used
	     to check the remaining arguments.

     /* PROTOLIBn */
	     causes lint to treat function declaration prototypes as function
	     definitions if n is non-zero.  This directive can only be used in
	     conjunction with the /* LINTLIBRARY */ directive.	If n is zero,
	     function prototypes will be treated normally.

     /* SCANFLIKEn */
	     makes lint check the first (n-1) arguments as usual.  The n-th
	     argument is interpreted as a scanf(3) format string that is used
	     to check the remaining arguments.

     /* VARARGSn */
	     Suppress the usual checking for variable numbers of arguments in
	     the following function declaration.  The data types of the first
	     n arguments are checked; a missing n is taken to be 0.

     The behavior of the -i and the -o options allows for incremental use of
     lint on a set of C source files.  Generally, one invokes lint once for
     each source file with the -i option.  Each of these invocations produces
     a .ln file that corresponds to the .c file, and prints all messages that
     are about just that source file.  After all the source files have been
     separately run through lint, it is invoked once more (without the -i
     option), listing all the .ln files with the needed -l library options.
     This will print all the inter-file inconsistencies.  This scheme works
     well with make(1); it allows make(1) to be used to lint only the source
     files that have been modified since the last time the set of source files
     were linted.


     CC      Location of the C compiler program.  Defaults to /usr/bin/cc.


     /usr/libexec/lint[12]	   programs
     /usr/libdata/lint/llib-l*.ln  various prebuilt lint libraries
     /tmp/lint* 		   temporaries


     cc(1), cpp(1), make(1)


     Jochen Pohl


     The routines exit(3), longjmp(3) and other functions that do not return
     are not understood; this causes various incorrect diagnostics.

     Static functions which are used only before their first extern declara-
     tion are reported as unused.

     Libraries created by the -o option will, when used in later lint runs,
     cause certain errors that were reported when the libraries were created
     to be reported again, and cause line numbers and file names from the
     original source used to create those libraries to be reported in error
     messages.	For these reasons, it is recommended to use the -C option to
     create lint libraries.

FreeBSD 5.4			 May 24, 2001			   FreeBSD 5.4


Man(1) output converted with man2html , sed , awk