Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

FreeBSD 11.0 - man page for lint (freebsd section 1)

LINT(1) 			   BSD General Commands Manual				  LINT(1)

     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 values in some places and not in others, functions called with varying numbers 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 return-
     ing values that use the non-existent return value of the function.

     Filename arguments ending with .c are taken to be C source files.	Filename 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 routines and variables.

     The lint utility takes all the .c, .ln, and llib-llibrary.ln (lint library) files and pro-
     cesses 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 complaint 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 other integer values
	     which cause implicit narrowing conversion.

     -b      Report break statements that cannot be reached.  This is not the default because,
	     unfortunately, most lex(1) and many yacc(1) outputs produce many such complaints.

     -c      Complain about casts which have questionable portability.

     -e      Complain about unusual operations on enum-Types and combinations of enum- and

     -g      Do not print warnings for some extensions of gcc(1) to the C language.  Currently
	     these are nonconstant initializers in automatic aggregate initializations, arith-
	     metic on pointer to void, trailing commas in enum declarations, C++ -style ``//''
	     comments, zero sized structures, subscripting of non-lvalue arrays, prototypes over-
	     riding old style function declarations and long long integer types.  The -g flag
	     also turns on the keywords asm and inline (alternative keywords with leading under-
	     scores 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

     -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 declaration.

     -s      Strict ANSI C mode.  Issue warnings and errors required by ANSI C.  Also do not pro-
	     duce warnings for constructs which behave differently 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 keywords const, volatile and
	     signed are not available in traditional C mode (although the alternative keywords
	     with leading underscores still are).

     -u      Do not complain about functions and external variables used and not defined, or
	     defined and not used (this is suitable for running lint on a subset of files com-
	     prising part of a larger program).

     -v      Suppress complaints about unused arguments in functions.

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

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

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

     -C library
	     Create a lint library with the name llib-llibrary.ln.  This library is built from
	     all .c and .ln input files.  After all global definitions of functions and variables
	     in these files are written to the newly created library, lint checks all input
	     files, including libraries specified with the -l option, for mutual compatibility.

     -D name[=def]
	     Define name for cpp(1), as if by a #define directive.  If no definition 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 stan-
	     dard place.

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

     -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 out-
	     put file.	If the -i option is also used the files are not checked for compatibil-
	     ity.  To produce 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 pre-
	     processor 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 recognizes 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).

	     Suppress error messages about illegal bitfield types if the type is an integer type,
	     and suppress non-portable bitfield type warnings.

	     suppress complaints about constant operands for the next expression.

     /* 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 occurred.

     /* 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 inter-
	     preted 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 inter-
	     preted 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 func-
	     tion 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 incon-
     sistencies.  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

     LIBDIR  the directory where the lint libraries specified by the -l library option must
	     exist.  If this environment variable is undefined, then the default path
	     /usr/libdata/lint will be used to search for the libraries.

     TMPDIR  usually the path for temporary files can be redefined by setting this environment

     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 declaration are reported as

     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 num-
     bers 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

BSD					   May 24, 2001 				      BSD

All times are GMT -4. The time now is 07:53 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password