6    Checking C Programs with lint

The C language automatically converts data types within this group to provide the programmer with more flexibility in programming. This flexibility, however, means that the programmer, not the language, must ensure that the data type mixing produces the desired result.

You can mix these data types when using them in the following ways (in the examples, alpha is type char and num is type int):

• Operands on both sides of an assignment operator, for example:

  alpha = num;   /* alpha converts to int */
  

• Operands in a conditional expression, for example:

  value=(alpha < num) ? alpha : num;
  /* alpha converts to int */
  

• Operands on both sides of a relational operator, for example:

  if( alpha != num )  /* alpha converts to int */
  

• The type of an argument in a return statement is converted to the type of the value that the function returns, for example:

  funct(x)        /* returns an integer */
  {
    return( alpha );
  }
  

The data types of pointers must agree exactly, except that you can mix arrays of any type with pointers to the same type.

6.3.2    Structures and Unions

The lint program checks structure operations for the following requirements:

• The left operand of the structure pointer operator (->) must be a pointer to a structure.

• The left operand of the structure member operator (.) must be a structure.

• The right operand of these operators must be a member of the same structure.

The lint program makes similar checks for references to unions.

6.3.3    Function Definition and Uses

The lint program applies strict rules to function argument and return value matching. Arguments and return values must agree in type, with the following exceptions:

• You can match arguments of type float with arguments of type double.

• You can match arguments within the following types:

  char
  short
  int
  unsigned

• You can match pointers with the associated arrays.

6.3.4    Enumerators

The lint program checks enumerated data type variables to ensure that they meet the following requirements:

• Enumerator variables or members of an enumerated type are not mixed with other types or other enumerator variables.

• The enumerated data type variables are only used in the following areas:

  Assignment (=)
  Initialization
  Equivalence (==)
  Not equivalence (!=)
  Function arguments
  Return values

6.3.5    Type Casts

Type casts in the C language allow the program to treat data of one type as if it were data of another type. The lint program can check for type casts and write a message if it finds one.

The -wp and -h options for the lint command line control the writing of warning messages about casts. If neither of these options are used, lint produces warning messages about casts that may cause portability problems.

In migration checking mode, -Qc suppresses cast warning messages (see Section 6.6).

6.4    Variable and Function Checking

The lint program checks for variables and functions that are declared in a program but not used. The lint program checks for the following errors in the use of variables and functions:

• Functions that return values inconsistently

• Functions that are defined but not used

• Arguments to a function call that are not used

• Functions that can return either with or without values

• Functions that return values that are never used

• Programs that use the value of a function when the function does not return a value

Details on each of these potential problem areas are provided in the sections that follow.

6.4.1    Inconsistent Function Return

If a function returns a value under one set of conditions but not under another, you cannot predict the results of the program. The lint program checks functions for this type of behavior. For example, if both of the following statements are in a function definition, a program calling the function may or may not receive a return value:

return(expr);

.
.
.
return;

These statements cause the lint program to write the following message to point out the potential problem:

function name has return(e); and return

The lint program also checks functions for returns that are caused by reaching the end of the function code (an implied return). For example, in the following part of a function, if a tests false, checkout calls fix_it and then returns with no defined return value:

checkout (a)
{
        if (a) return (3);
        fix_it ();
}

These statements cause the lint program to write the following message:

function checkout has return(e); and return
 

If fix_it, like exit, never returns, lint still writes the message even though nothing is wrong.

6.4.2    Function Values That Are Not Used

The lint program checks for cases in which a function returns a value and the calling program may not use the value. If the value is never used, the function definition may be inefficient and should be examined to determine whether it should be modified or eliminated. If the value is sometimes used, the function may be returning an error code that the calling program does not check.

6.4.3    Disabling Function-Related Checking

To prevent lint from checking for problems with functions, specify one or more of the following options to the lint command:

You can also place directives in the program to control checking:

• To prevent lint from warning about unused function arguments, add the following directive to the program before the function definition:

  /*ARGSUSED*/

• To prevent lint from writing messages about variable numbers of arguments in calls to a function, add the following directive before the function definition:

  /*VARARGS n*/

  To check the first several arguments and leave the later arguments unchecked, add a digit (n) to the end of the VARARGS directive to give the number of arguments that should be checked, such as:

  /*VARARGS2*/

  When lint reads this directive, it checks only the first two arguments.

• To suppress complaints about unused functions and function arguments in an entire file, place the following directive at the beginning of the file:

  /*LINTLIBRARY*/

  This is equivalent to using the -v and -x options.

• To permit a standard prototype checking library to be formed from header files by making function prototype declarations appear as function definitions, use the following directive:

  /*LINTSTDLIB[ _filename ]*/

  The /*LINTSTDLIB*/ directive implicitly activates the functions of the /*NOTUSED*/ and /*LINTLIBRARY*/ directives to reduce warning noise levels. When a file is referenced (filename), only prototypes in that file are expanded. Multiple /*LINTSTDLIB_filename */ statements are allowed. (See Section 6.10.1 for more details on the use of /*LINTSTDLIB*/ directives.)

• To suppress warnings about all used but undefined external symbols and functions that are subsequently encountered in the file, use the following directive:

  /*NOTDEFINED*/

• To suppress comments about unreachable code, use the following directive:

  /*NOTREACHED*/

  When placed at appropriate points in a program (typically immediately following a return, break, or continue statement), the /*NOTREACHED*/ directive stops comments about unreachable code. Note that lint does not recognize the exit function and other functions that may not return.

• To suppress warnings about all unused external symbols, functions, and function parameters that are subsequently encountered in the file, use the following directive:

  /*NOTUSED*/

  The /*NOTUSED*/ directive is similar to the /*LINTLIBRARY*/ directive, although /*NOTUSED*/ also applies to external symbols.

6.5    Checking on the Use of Variables Before They Are Initialized

The lint program checks for the use of a local variable (auto and register storage classes) before a value has been assigned to it. Using a variable with an auto (automatic) or register storage class also includes taking the address of the variable. This is necessary because the program can use the variable (through its address) any time after it knows the address of the variable. Therefore, if the program does not assign a value to the variable before it finds the address of the variable, lint reports an error.

Because lint only checks the physical order of the variables and their usage in the file, it may write messages about variables that are initialized properly (in execution sequence).

The lint program recognizes and writes messages about:

• Initialized automatic variables

• Variables that are used in the expression that first sets them

• Variables that are set and never used

Note

The Tru64 UNIX operating system initializes static and extern variables to zero. Therefore, lint assumes that these variables are set to zero at the start of the program and does not check to see if they have been assigned a value when they are used. When developing a program for a system that does not do this initialization, ensure that the program sets static and extern variables to an initial value.

6.6    Migration Checking

Use lint to check for all common programming techniques that might cause problems when migrating programs from 32-bit operating systems to the Tru64 UNIX operating system. The -Q option provides support for checking ULTRIX and DEC OSF/1 Version 1.0 programs that you are migrating to 64-bit systems.

Because the -Q option disables checking for most other programming problems, use this option only for migration checking. Suboptions are available to suppress specific categories of checking. For example, entering -Qa suppresses the checking of pointer alignment problems. You can enter more than one suboption with the -Q option, for example, -QacP to suppress checking for pointer alignment problems, problematic type casts, and function prototype checks, respectively. For more information about migration checking, see lint(1).

6.7    Portability Checking

Use lint to help ensure that you can compile and run C programs using different C language compilers and other systems.

The following sections indicate areas to check before compiling the program on another system. Checking only these areas, however, does not guarantee that the program will run on any system.

Note

The llib-port.ln library is brought in by using the -p option, not by using the -lport option.

6.7.1    Character Uses

Some systems define characters in a C language program as signed quantities with a range from -128 to 127; other systems define characters as positive values. The lint program checks for character comparisons or assignments that may not be portable to other systems. For example, the following fragment may work on one system but fail on systems where characters always take on positive values:

char c;

.
.
.
if( ( c = getchar() ) <0 )...

This statement causes the lint program to write the following message:

nonportable character comparison

To make the program work on systems that use positive values for characters, declare c as an integer because getchar returns integer values.

6.7.2    Bit Field Uses

Bit fields may produce problems when a program is transferred to another system. Bit fields may be signed quantities on the new system. Therefore, when constant values are assigned to a bit field, the field may be too small to hold the value. To make this assignment work on all systems, declare the bit field to be of type unsigned before assigning values to it.

6.7.3    External Name Size

When changing from one type of system to another, be aware of differences in the information retained about external names during the loading process:

• The number of characters allowed for external names can vary.

• Some programs that the compiler command calls and some of the functions that your programs call can further limit the number of significant characters in identifiers. (In addition, the compiler adds a leading underscore to all names and keeps uppercase and lowercase characters separate.)

• On some systems, uppercase or lowercase may not be important or may not be allowed.

When transferring from one system to another, you should always take the following steps to avoid problems with loading a program:

1. Review the requirements of each system.

2. Run lint with the -p option.

The -p option tells lint to change all external symbols to lowercase and limit them to six characters while checking the input files. The messages produced identify the terms that may need to be changed.

6.7.4    Multiple Uses and Side Effects

Be careful when using complicated expressions because of the following considerations:

• The order in which complex expressions are evaluated differs in many C compilers.

• Function calls that are arguments of other functions may not be treated the same as ordinary arguments.

• Operators such as assignment, increment, and decrement may cause problems when used on different systems.

The following situations demonstrate the types of problems that can result from these differences:

• If any variable is changed by a side effect of one of the operators and is also used elsewhere in the same expression, the result is undefined.

• The evaluation of the variable years in the following printf statement is confusing because on some machines years is incremented before the function call and on other machines it is incremented after the function call:

  printf( "%d %d\n", ++years, amort( interest, years ) );
  

• The lint program checks for simple scalar variables that may be affected by evaluation order problems, such as in the following statement:

  a[i]=b[i++];
  

  This statement causes the lint program to write the following message:

  warning: i evaluation order undefined
  

6.8    Checking for Coding Errors and Coding Style Differences

Use lint to detect possible coding errors, and to detect differences from the coding style that lint expects. Although coding style is mainly a matter of individual taste, examine each difference to ensure that the difference is both needed and accurate. The following sections indicate the types of coding and style problems that lint can find.

6.8.1    Assignments of Long Variables to Integer Variables

If you assign variables of type long to variables of type int, the program may not work properly. The long variable is truncated to fit in the integer space and data may be lost.

An error of this type frequently occurs when a program that uses more than one typedef is converted to run on a different system.

To prevent lint from writing messages when it detects assignments of long variables to int variables, use the -a option.

6.8.2    Operator Precedence

The lint program detects possible or potential errors in operator precedence. Without parentheses to show order in complex sequences, these errors can be hard to find. For example, the following statements are not clear:

 if(x&077==0). . .   /* evaluated as: if(x & (077 == 0) ) */
                     /* should be: if( (x & 077) == 0) */
 
 x<<2+40             /* evaluated as: x <<(2+40) */
                     /* should be: (x<<2) + 40 */
                     /* shift x left 42 positions */

Use parentheses to make the operation more clearly understood. If you do not, lint issues a message.

6.8.3    Conflicting Declarations

The lint program writes messages about variables that are declared in inner blocks in ways that conflict with their use in outer blocks. This practice is allowed, but may cause problems in the program.

Use the -h option with the lint program to prevent lint from checking for conflicting declarations.

6.9    Increasing Table Size

The lint command provides the -N option and related suboptions to allow you to increase the size of various internal tables at run time if the default values are not enough for your program. These tables include:

• Symbol table

• Dimension table

• Local type table

• Parse tree

These tables are dynamically allocated by the lint program. Using the -N option on large source files can improve performance.

6.10    Creating a lint Library

For programming projects that define additional library routines, you can create an additional lint library to check the syntax of the programs. Using this library, the lint program can check the new functions in addition to the standard C language functions. To create a new lint library, follow these steps:

1. Create an input file that defines the new functions.

2. Process the input file to create the lint library file.

3. Run lint using the new library.

The following sections describe these steps.

6.10.1    Creating the Input File

The following example shows an input file that defines three additional functions for lint to check:

/*LINTLIBRARY*/
 
#include <dms.h>
 
int  dmsadd( rmsdes, recbuf, reclen )
               int rmsdes;
               char *recbuf;
               unsigned reclen;
             { return 0; }
int  dmsclos( rmsdes)
               int rmsdes;
             { return 0; }
int  dmscrea( path, mode, recfm, reclen )
               char *path;
               int mode;
               int recfm;
               unsigned reclen;
             { return 0; }

The input file is a text file that you create with an editor. It consists of:

• A directive to tell the cpp program that the following information is to be made into a library of lint definitions:

  /*LINTLIBRARY*/
  

• A series of function definitions that define:

  • The type of the function (int in the example)

  • The name of the function

  • The parameters that the function expects

  • The types of the parameters

  • The value that the function returns

Alternatively, you can create a lint library file from function prototypes. For example, assume that the dms.h file includes the following prototypes:

int dmsadd(int,
           char*,
           unsigned);
int dmsclose(int);
int dmscrea(char*,
            int,
            int,
            unsigned);

In this case, the input file contains the following:

/*LINTSTDLIB*/
#include <dms.h>

In the case where a header file may include other headers, the LINTSTDLIB command can be restricted to specific files:

/*LINTSTDLIB_dms.h*/

In this case, only prototypes declared in dms.h will be expanded. Multiple LINTSTDLIB commands can be included.

In all cases, the name of the input file must have the prefix llib-l. For example, the name of the sample input file created in this section could be llib-ldms. When choosing the name of the file, ensure that it is not the same as any of the existing files in the /usr/ccs/lib directory.

6.10.2    Creating the lint Library File

The following command creates a lint library file from the input file described in the previous section:

% lint [options] -c llib_ldms.c

This command tells lint to create a lint library file, llib-ldms.ln, using the file llib-ldms.c as input. To use llib-ldms.ln as a system lint library (that is, a library specified in the -lx option of the lint command), move it to /usr/ccs/lib. Use the -std or -std1 option to use ANSI preprocessing rules to build the library.

6.10.3    Checking a Program with a New Library

To check a program using a new library, use the lint command with the following format:

lint -lpgm filename.c
        

The variable pgm represents the identifier for the library, and the variable filename.c represents the name of the file containing the C language source code that is to be checked. If no other options are specified, the lint program checks the C language source code against the standard lint library in addition to checking it against the indicated special lint library.

6.11    Understanding lint Error Messages

Although most error messages produced by lint are self-explanatory, certain messages may be misleading without additional explanation. Usually, once you understand what a message means, correcting the error is straightforward. The following is a list of the more ambiguous lint messages:

constant argument to NOT

A constant is used with the NOT operator (!). This is a common coding practice and the message does not usually indicate a problem. The following program demonstrates the type of code that can generate this message:

% cat x.c
#include <stdio.h>
#define SUCCESS    0
 
main()
{
	  int value = !SUCCESS;
 
	  printf("value = %d\n", value);
	  return 0;
}
% lint -u x.c
"x.c", line 7: warning: constant argument to NOT
% ./x
value = 1
% 

The program runs as expected, even though lint complains.

Recommended Action: Suppress these lint warning messages by using the -wC option.

constant in conditional context

A constant is used where a conditional is expected. This problem occurs often in source code due to the way in which macros are encoded. For example:

typedef struct _dummy_q {
  int lock;
  struct _dummy_q *head, *tail;
} DUMMY_Q;
 
#define QWAIT   1
#define QNOWAIT 0
#define DEQUEUE(q, elt, wait)    [1]         \
        for (;;) {                           
            simple_lock(&(q)->lock);         
        if (queue_empty(&(q)->head))         
            if (wait) {          [1]         \
                assert(q);                   
                simple_unlock(&(q)->lock);   
                continue;                    
            } else                           
                *(elt) = 0;                  
        else                                 
                  dequeue_head(&(q)->head);  
                  simple_unlock(&(q)->lock); 
        break;                               
    }
 
int doit(DUMMY_Q *q, int *elt)
{
  DEQUEUE(q, elt, QNOWAIT);
}

1. The QWAIT or QNOWAIT option is passed as the third argument (wait) and is later used in the if statement. The code is correct, but lint issues the warning because constants used in this way are normally unnecessary and often generate wasteful or unnecessary instructions. [Return to example]

Recommended Action: Suppress these lint warning messages by using the -wC option.

conversion from long may lose accuracy

A signed long is copied to a smaller entity (for example, an int). This message is not necessarily misleading; however, if it occurs frequently, it may or may not indicate a coding problem, as shown in the following example:

long BuffLim = 512;         [1]
 
void foo (buffer, size)
char *buffer;
int size;
{
register int count;
register int limit = size < (int)BufLimit ? size : (int)BufLim;  [1]
 
 

1. The lint program reports the conversion error, even though the appropriate (int) cast exists. [Return to example]

Recommended Action: Review code sections for which lint reports this message, or suppress the message by using the -wl option.

declaration is missing declarator

A line in the declaration section of the program contains just a semicolon (;). Although you would not deliberately write code like this, it is easy to inadvertently generate such code by using a macro followed by a semicolon. If, due to conditionalization, the macro is defined as empty, this message can result.

Recommended Action: Remove the trailing semicolon.

degenerate unsigned comparison

An unsigned comparison is being performed against a signed value when the result is expected to be less than zero. The following program demonstrates this situation:

% cat x.c
#include <stdio.h>
unsigned long offset = -1;
 
main()
{
    if (offset < 0) {               [1]
        puts ("code is Ok...");
        return 0;
    } else {
        puts ("unsigned comparison failed...");
        return 1;
    }
}
% cc -g -o x x.c
% lint x.c
"x.c" line 7: warning: degenerate unsigned comparison
% ./x
unsigned comparison failed...
% 

1. Unsigned comparisons such as this will fail if the unsigned variable contains a negative value. The resulting code may be correct, depending upon whether the programmer intended a signed comparison. [Return to example]

Recommended Action: You can fix the previous example in two ways:

• Add a (long) cast before offset in the if comparison.

• Change the declaration of offset from unsigned long to long.

In certain cases, it might be necessary to cast the signed value to unsigned.

function prototype not in scope

This error is not strictly related to function prototypes, as the message implies. Actually, this error occurs from invoking any function that has not been previously declared or defined.

Recommended Action: Add the function prototype declaration.

null effect

The lint program detected a cast or statement that does nothing. The following code segments demonstrate various coding practices that cause lint to generate this message:

    scsi_slot = device->ctlr_hd->slot,unit_str;     [1]
 
    #define MCLUNREF(p)             \
            (MCLMAPPED(p) && --mclrefcnt[mtocl(p)] == 0)
 
    (void) MCLUNREF(m);                             [2]
 
 

1. Reason: unit_str does nothing. [Return to example]

2. Reason: (void) is unnecessary; MCLUNREF is a macro. [Return to example]

Recommended Action: Remove unnecessary casts or statements, or update macros.

possible pointer alignment problem

A pointer is used in a way that may cause an alignment problem. The following code segment demonstrates the type of code that causes lint to generate this message:

read(p, args, retval)
        struct proc *p;
        void *args;
        long *retval;
{
        register struct args {
                long    fdes;
                char    *cbuf;
                unsigned long  count;
        } *uap = (struct args *) args;          [1]
        struct uio auio;
        struct iovec aiov;

1. The line *uap = (struct args *) args causes the error to be reported. Because this construct is valid and occurs throughout the kernel source, this message is filtered out. [Return to example]

precision lost in field assignment

An attempt was made to assign a constant value to a bit field when the field is too small to hold the value. The following code segment demonstrates this problem:

% cat x.c
struct bitfield {
    unsigned int block_len : 4;
} bt;
 
void
test()
{
    bt.block_len = 0xff;
}
% lint -u x.c
"x.c", line 8: warning: precision lost in field assignment
% cc -c -o x x.c
%

This code compiles without error. However, because the bit field may be too small to hold the constant, the results may not be what the programmer intended and a run-time error may occur.

Recommended Action: Change the bit field size or assign a different constant value.

unsigned comparison with 0

An unsigned comparison is being performed against zero when the result is expected to be equal to or greater than zero.

The following program demonstrates this problem:

% cat z.c
#include <stdio.h>
unsigned offset = -1;
 
main()
{
    if (offset > 0) {               [1]
        puts("unsigned comparison with 0 Failed");
        return 1;
    } else {
        puts("unsigned comparison with 0 is Ok");
        return 0;
    }
}
% cc -o z z.c
% lint z.c
"z.c", line 7: warning: unsigned comparison with 0?
% ./z
unsigned comparison with 0 Failed
% 

1. Unsigned comparisons such as this will fail if the unsigned variable contains a negative value. The resulting code may not be correct, depending on whether the programmer intended a signed comparison. [Return to example]

Recommended Action: You can fix the previous example in two ways:

• Add an (int) cast before offset in the if comparison.

• Change the declaration of offset from unsigned to int.

6.12    Using Warning Class Options to Suppress lint Messages

Several lint warning classes have been added to the lint program to allow the suppression of messages associated with constants used in conditionals, portability, and prototype checks. By using the warning class option to the lint command, you can suppress messages in any of the warning classes.

The warning class option has the following format:

-wclass [ class... ]

All warning classes are active by default, but may be individually deactivated by including the appropriate option as part of the class argument. Table 6-1 lists the individual options.

Note

Several lint messages depend on more than one warning class. Therefore, you may need to specify several warning classes for the message to be suppressed. Notes in Table 6-1 indicate which messages can be suppressed only by specifying multiple warning classes.

For example, because lint messages related to constants in conditional expressions do not necessarily indicate a coding problem (as described in Section 6.11), you may decide to use the -wC option to suppress them.

The -wC option suppresses the following messages:

• constant argument to NOT

• constant in conditional context

Because many of the messages associated with portability checks are related to non-ANSI compilers and limit restrictions that do not exist in the C compiler for Tru64 UNIX, you can use the -wp option to suppress them. The -wp option suppresses the following messages:

• ambiguous assignment for non-ansi compilers

• illegal cast in a constant expression

• long in case or switch statement may be truncated in non-ansi compilers

• nonportable character comparison

• possible pointer alignment problem, op %s

• precision lost in assignment to (sign-extended?) field

• precision lost in field assignment

• too many characters in character constant

Although the use of function prototypes is a recommended coding practice (as described in Section 6.13), many programs do not include them. You can use the -wP option to suppress prototype checks. The -wP option suppresses the following messages:

• function prototype not in scope

• mismatched type in function argument

• mix of old and new style function declaration

• old style argument declaration

• use of old-style function definition in presence of prototype

Table 6-1:  lint Warning Classes

6.13    Generating Function Prototypes for Compile-Time Detection of Syntax Errors

In addition to correcting the various errors reported by the lint program, we recommend adding function prototypes to your program for both external and static functions. These declarations provide the compiler with information it needs to check arguments and return values.

The cc compiler provides an option that automatically generates prototype declarations. By specifying the -proto[is] option for a compilation, you create an output file (with the same name as the input file but with a .H extension) that contains the function prototypes. The i option includes identifiers in the prototype, and the s option generates prototypes for static functions as well.

You can copy the function prototypes from a .H file and place them in the appropriate locations in the source and include files.