JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.3: C User's Guide     Oracle Solaris Studio 12.3 Information Library
search filter icon
search icon

Document Information


1.  Introduction to the C Compiler

2.  C-Compiler Implementation-Specific Information

3.  Parallelizing C Code

4.  lint Source Code Checker

4.1 Basic and Enhanced lint Modes

4.2 Using lint

4.3 lint Command-Line Options

4.3.1 -#

4.3.2 -###

4.3.3 -a

4.3.4 -b

4.3.5 -C filename

4.3.6 -c

4.3.7 -dirout=dir

4.3.8 -err=warn

4.3.9 -errchk=l(, l)

4.3.10 -errfmt=f

4.3.11 -errhdr=h

4.3.12 -erroff=tag(, tag)

4.3.13 -errsecurity=level

4.3.14 -errtags=a

4.3.15 -errwarn=t

4.3.16 -F

4.3.17 -fd

4.3.18 -flagsrc=file

4.3.19 -h

4.3.20 -Idir

4.3.21 -k

4.3.22 -Ldir

4.3.23 -lx

4.3.24 -m

4.3.25 -m32|-m64

4.3.26 -Ncheck=c

4.3.27 -Nlevel=n -Nlevel=1 -Nlevel=2 -Nlevel=3 -Nlevel=4

4.3.28 -n

4.3.29 -ox

4.3.30 -p

4.3.31 -Rfile

4.3.32 -s

4.3.33 -u

4.3.34 -V

4.3.35 -v

4.3.36 -Wfile

4.3.37 -XCC=a

4.3.38 -Xalias_level[=l]

4.3.39 -Xarch=amd64

4.3.40 -Xarch=v9

4.3.41 -Xc99[=o]

4.3.42 -Xkeeptmp=a

4.3.43 -Xtemp=dir

4.3.44 -Xtime=a

4.3.45 -Xtransition=a

4.3.46 -Xustr={ascii_utf16_ushort|no}

4.3.47 -x

4.3.48 -y

4.4 lint Messages

4.4.1 Options to Suppress Messages

4.4.2 lint Message Formats

4.5 lint Directives

4.5.1 Predefined Values

4.5.2 Directives

4.6 lint Reference and Examples

4.6.1 Diagnostics Performed by lint Consistency Checks Portability Checks Questionable Constructs

4.6.2 lint Libraries

4.6.3 lint Filters

5.  Type-Based Alias Analysis

6.  Transitioning to ISO C

7.  Converting Applications for a 64-Bit Environment

8.  cscope: Interactively Examining a C Program

A.  Compiler Options Grouped by Functionality

B.  C Compiler Options Reference

C.  Implementation-Defined ISO/IEC C99 Behavior

D.  Features of C99

E.  Implementation-Defined ISO/IEC C90 Behavior

F.  ISO C Data Representations

G.  Performance Tuning

H.  Oracle Solaris Studio C: Differences Between K&R C and ISO C


4.6 lint Reference and Examples

This section provides reference information on lint, including checks performed by lint, lint libraries, and lint filters.

4.6.1 Diagnostics Performed by lint

lint-specific diagnostics are issued for three broad categories of conditions: inconsistent use, nonportable code, and questionable constructs. This section reviews examples of lint’s behavior in each of these areas, and suggests possible responses to the issues they raise. Consistency Checks

Inconsistent use of variables, arguments, and functions is checked within files as well as across them. Generally speaking, the same checks are performed for prototype uses, declarations, and parameters as lint checks for old-style functions. If your program does not use function prototypes, lint checks the number and types of parameters in each call to a function more strictly than the compiler. lint also identifies mismatches of conversion specifications and arguments in [fs]printf() and [fs]scanf() control strings.

Examples: Portability Checks

Some nonportable code is flagged by lint in its default behavior, and a few more cases are diagnosed when lint is invoked with -p or -Xc. The latter causes lint to check for constructs that do not conform to the ISO C standard. For the messages issued under -p and -Xc, see 4.6.2 lint Libraries.

Examples: Questionable Constructs

lint flags a miscellany of legal constructs that might not represent what the programmer intended. Examples:

4.6.2 lint Libraries

You can use lint libraries to check your program for compatibility with the library functions you have called in it: the declaration of the function return type, the number and types of arguments the function expects, and so on. The standard lint libraries correspond to libraries supplied by the C compilation system, and generally are stored in a standard place on your system. By convention, lint libraries have names of the form llib-lx.ln.

The lint standard C library, llib-lc.ln, is appended to the lint command line by default. Checks for compatibility with it can be suppressed by invoking the -n option. Other lint libraries are accessed as arguments to -l. The following example directs lint to check the usage of functions and variables in file1.c and file2.c for compatibility with the lint library llib-lx.ln.

% lint -lx file1.c file2.c

The library file, which consists only of definitions, is processed exactly as are ordinary source files and ordinary .ln files, except that functions and variables used inconsistently in the library file, or defined in the library file but not used in the source files, elicit no complaints.

To create your own lint library, insert the directive NOTE(LINTLIBRARY) at the head of a C source file, then invoke lint for that file with the -o option and the library name given to -l. The following example causes only definitions in the source files headed by NOTE(LINTLIBRARY) to be written to the file llib-lx.ln.

% lint -ox file1.c file2.c

Note the analogy of lint -o to cc -o. A library can be created from a file of function prototype declarations in the same way, except that both NOTE(LINTLIBRARY) and NOTE(PROTOLIB(n))must be inserted at the head of the declarations file. If n is 1, prototype declarations are written to a library .ln file just as are old-style definitions. If n is 0, the default, the process is cancelled. Invoking lint with -y is another way of creating a lint library. The following command line causes each source file named on that line to be treated as if it begins with NOTE(LINTLIBRARY), and only its definitions to be written to llib-lx.ln.

% lint -y -ox file1.c file2.c

By default, lint searches for lint libraries in the standard place. To direct lint to search for a lint library in a directory other than the standard place, specify the path of the directory with the -L option:

% lint -Ldir -lx file1.c file2.c

In enhanced mode, lint produces .ln files which store additional information than .ln files produced in basic mode. In enhanced mode, lint can read and understand all .ln files generated by either basic or enhanced lint modes. In basic mode, lint can read and understand .ln files generated only using basic lint mode.

By default, lint uses libraries from the /usr/lib directory. These libraries are in the basic lint format. You can run a makefile once, and create enhanced lint libraries in a new format, which will enable enhanced lint to work more effectively. To run the makefile and create the new libraries, use the following command:

% cd install-directory/prod/src/lintlib; make

where install-directory is the installation directory. After the makefile is run, lint uses the new libraries in enhanced mode, instead of the libraries in the /usr/lib directory.

The specified directory is searched before the standard locations.

4.6.3 lint Filters

A lint filter is a project-specific post-processor that typically uses an awk script or similar program to read the output of lint and discard messages that your project has deemed as not identifying real problems, for example, string functions, that, return values that are sometimes or always ignored. lint filters generate customized diagnostic reports when lint options and directives do not provide sufficient control over output.

Two options to lint are particularly useful in developing a filter: