Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
LINT(1) 		     General Commands Manual			 LINT(1)

NAME
     lint -- a C program verifier

SYNOPSIS
     lint [-abceghprvwxzHFV] [-s | -t] [-i | -nu] [-D name[=def]] [-U name]
	  [-I directory] [-d directory] [-L directory] [-MD] [-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 ...

DESCRIPTION
     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 state-
     ments,  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  argu-
     ments, 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.	Filename
     arguments	with names ending with .ln are taken to be the result of an ear-
     lier 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 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 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 in-
     put (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  fol-
     lows:

     -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)  out-
	     puts 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 integer-Types.

     -g      Do  not  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, trailing
	     commas in enum declarations, C++ -style "//" comments,  zero  sized
	     structures,  subscripting of non-lvalue arrays, prototypes overrid-
	     ing 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  al-
	     ways available).

     -h      Apply  a  number  of heuristic tests to attempt to intuit bugs, im-
	     prove 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  dec-
	     laration.

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

     -S      C9X mode. Currently not fully implemented.

     -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 ma-
	     chine 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 comprising 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 exam-
	     ple, using a structure pointer without knowing its contents).

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

     -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 defini-
	     tions  of functions and variables in these files are written to the
	     newly created library, lint checks all input files,  including  li-
	     braries specified with the -l option, for mutual compatibility.

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

     -I directory
	     Add directory to the list of directories in which to search for in-
	     clude 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.

     -MD     Pass -MD to cpp(1) causing cpp to create  files  containing  depen-
	     dency information for each source file.

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

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

     /* CONSTCOND */ or /* CONSTANTCOND */ or /* CONSTANTCONDITION */
	     suppress  complaints  about  constant operands for the next expres-
	     sion.

     /* FALLTHRU */ or /* FALLTHROUGH */
	     suppress complaints about fall through to a  case	or  default  la-
	     belled statement.	This directive should be placed immediately pre-
	     ceding the label.

     /* LINTLIBRARY */
	     At  the  beginning  of a file, mark all functions and variables de-
	     fined 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 ar-
	     gument 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  ar-
	     gument  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 sepa-
     rately 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.

ENVIRONMENT
     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 variable.

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

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

SEE ALSO
     cc(1), cpp(1), make(1)

AUTHORS
     Jochen Pohl

BUGS
     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 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 11.2			  Mar 23, 2015				 LINT(1)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=lint&manpath=FreeBSD+11.2-RELEASE>

home | help