Using lint

The lint command objects if source code declares a variable that is never used or defines a function that is never called. Unused variables and functions are considered bad style because their declarations clutter the code.

Unused static identifiers cause the following message:

(1)static identifier 'name' defined but never used

Unused automatic variables cause the following message:

(1) warning: 'name' unused in function 'name'

A function or external variable that is unused causes the message

name defined but never used

followed by the function or variable name, the line number and file in which it was defined. The lint command also looks at the special case where one of the parameters of a function is not used. The warning message is:

warning: (line number) 'arg_name' in func_name'

If functions or external variables are declared but never used or defined, lint responds with

name declared but never used or defined

followed by a list of variable and functions names and the names of files where they were declared.

Sometimes it is necessary to have unused function parameters to support consistent interfaces between functions. The -v option can be used with lint to suppress warnings about unused parameters.

If lint is run on a file that is linked with other files at compile time, many external variables and functions can be defined but not used, as well as used but not defined. If there is no guarantee that the definition of an external object is always seen before the object code is used, it is declared extern. The -u option can be used to stop complaints about all external objects, whether or not they are declared extern. If you want to inhibit complaints about only the extern declared functions and variables, use the -x option.

A problem exists in a program if a variable's value is used before it is assigned. Although lint attempts to detect occurrences of this, it takes into account only the physical location of the code. If code using a local variable is located before the variable is given a value, the message is:

warning: 'name' may be used before set

The lint command also objects if automatic variables are set in a function but not used. The message given is:

warning: 'name' set but not used in function 'func_name'

Note that lint does not have an option for suppressing the display of warnings for variables that are used but not set or set but not used.

The lint command checks for three types of unreachable code. Any statement following a goto, break, continue, or return statement must either be labeled or reside in an outer block for lint to consider it reachable. If neither is the case, lint responds with:

warning: (line number) statement not reached

The same message is given if lint finds an infinite loop. It only checks for the infinite loop cases of while(1) and for(;;). The third item that lint looks for is a loop that cannot be entered from the top. If one is found, then the message sent is:

warning: loop not entered from top

The lint command's detection of unreachable code is by no means exhaustive. Warning messages can be issued about valid code, and conversely lint may overlook code that cannot be reached.

Programs that are generated by yacc or lex can have many unreachable break statements. Normally, each one causes a complaint from lint. The -b option can be used to force lint to ignore unreachable break statements.

The C compiler allows a function containing both the statement

return();

and the statement

return(expression);

to pass through without complaint. The lint command, however, detects this inconsistency and responds with the message:

warning: function 'name' has 'return(expression)' and 'return'

The most serious difficulty with this is detecting when a function return is implied by flow of control reaching the end of the function. This can be seen with a simple example:

f(a)
{
    if (a) return (3);
    g();
}

Notice that is a tests false, f will call g and then return with no defined value. This will trigger a message for lint. If g (like exit) never returns, the message will still be produced when in fact nothing is wrong. In practice, some potentially serious bugs have been discovered by this feature.

On a global scale, lint detects cases where a function returns a value that is sometimes or never used. When the value is never used, it may constitute an inefficiency in the function definition. When the value is sometimes used, it may represent bad style (e.g., not testing for error conditions).

The lint command will not issue a diagnostic message if that function call is cast as void. For example,

(void) printf("%d\n",i);

tells lint to not warn about the ignored return value.

The dual problem — using a function value when the function does not return one — is also detected. This is a serious problem.

The lint command does not have an option for suppressing the display of warning for inconsistent return functions and functions that return no value.

The -p option of lint aids the programmer is writing portable code in four areas:

Character representation varies on different machines. Characters may be implemented as signed values. As a result, certain comparisons with characters give different results on different machines. The expression

c<0

where c is defined as type char, is always false if characters are unsigned values. If, however, characters are signed values, the expression could be either true or false. Where character comparisons could result in different values depending on the machine used, lint outputs the message:

warning: nonportable character comparison

Legal pointer assignments are determined by the alignment restrictions of the particular machine used. For example, one machine may allow double-precision values to begin on any modulo-4 boundary, but another may restrict them to modulo-8 boundaries. If alignment requirements are different, code containing an assignment of a double pointer to an integer pointer could cause problems. The lint command attempts to detect where the effect of pointer assignments is machine dependent. The warning that it outputs is:

warning: possible pointer alignment problem

The amount of information about external symbols that is loaded depends on: the machine being used, the number of significant characters, and whether or not uppercase/lowercase distinction is kept. The lint -p command truncates all external symbols to six characters and allows only one case distinction. (It changes uppercase characters to lowercase.) This provides a worst-case analysis so that the uniqueness of an external symbol is not machine-dependent.

The effectiveness of type casting in C programs can depend on the machine that is used. For this reason, lint ignores type casting code. All assignments that use it are subject to lint's type checking.

The -s option of the lint command checks for the following portability considerations:

The checks made for pointer alignments are exactly the same as for the -p option. The warning for these cases is:

warning: possible pointer alignment problem

The alignment of structure members is different between architectures. For example, MC680x0 computers pad structures internally so that all fields of type int begin on an even boundary. In contrast, PA-RISC computers pad structures so that all fields of type int begin on a four-byte boundary. The following structure will be aligned differently on the two architectures:

struct s
   { char c;
     long l; /* The offset equals 2 on MC680x0 computers */
   };        /* and 4 on PA-RISC computers.              */

In many cases the different alignment of structures does not affect the behavior of a program. However, problems can happen when raw structures are written to a file on one architecture and read back in on another. The lint command checks for cases where a structure member is aligned on a boundary that is not a multiple of its size (for example, int on int boundary, short on short boundary, and double on double boundary). The warning that it outputs is:

warning: alignment of struct 'name' may not be portable

The lint command also checks for cases where the internal padding added at the end of a structure may differ between architectures. The amount of trailing padding can change the size of a structure. The warning that lint outputs is:

warning: trailing padding of struct/union 's' may not be portable

A strange construction is code that lint considers to be bad style or a possible bug.

The lint command looks for code that has no effect. For example,

*p++;

where the * has no effect. The statement is equivalent to "p++;". In cases like this, the message

warning: null effect

is sent.

The treatment of unsigned numbers as signed numbers in comparison causes lint to report the following:

warning: degenerate unsigned comparison

The following code would produce such a message:

unsigned x;
   .
   .
   .
if (x >=0) ...

The lint command also objects if constants are treated as variables. If the boolean expression in a conditional has a set value due to constants, such as

if(1 !=0) ...

lint's response is:

warning: constant in conditional context

To avoid operator precedence confusion, lint encourages using parentheses in expressions by sending the message:

warning: precedence confusion possible: parenthesize!

The lint command judges it bad style to redefine an outer block variable in an inner block. Variables with different meanings should normally have different names. If variables are redefined, the message sent is:

warning: name redefinition hides earlier one

The -h option suppresses lint diagnostics of strange constructions.

The lint libraries are arranged for standards checking. For example,

lint -D_POSIX_SOURCE file.c

checks for routines referenced in file.c but not specified in the POSIX standard.

The lint command also accepts ANSI standard C -Aa as well as compatible C -Ac. In ANSI mode, lint invokes the ANSI preprocessor (/lib/cpp.ansi) instead of the compatibility preprocessor (/lib/cpp). ANSI mode lint should be used on source that is compiled with the ANSI standard C compiler.