One of the reasons for using LINT is to locate source code that may not be portable. Usually, code is non-portable because it uses features of the C compiler that may not be supported by other compilers. However, non-portability may also arise if your program calls functions which are in your implementation's library but which are not likely to be found in the libraries of other implementations. Similarly, non-portability may arise if a function in your implementation is not exactly the same as the same function in other implementations. (For example, the "abort" function in your implementation is somewhat different than most other "abort" functions.)
In order to detect non-portability arising from the use of library functions, LINT makes use of two different LINT libraries. One of these libraries contains LINT definitions based on the functions described in the November 1985 draft proposal of the ANSI standard for C. This is the "standard" library.
The other LINT library contains LINT definitions for all other functions supported by your C implementation, as well as definitions for functions that differ from the standard version. This is the "local" library.
By default, LINT looks up library functions in the local LINT library before it checks the standard LINT library. This means you will receive a warning message if
Note what happens in situations where the local version of a function differs from the standard version. Since LINT checks the local library first, LINT will find the local definition. This means that your program will receive an error if it differs from the local definition.
What we have just described is the default action. If you specify LINT's "-Local" option, the action is much different. In this case, LINT does not check the local library at all. You will receive new warning messages about every function that appears in the local library but not in the standard one. You will also receive new warning messages about functions that are used in the local way, not the standard way.
In the same way that LINT has local and standard libraries, LINT has local and standard #include files. For example, the standard version of <stdio.h> only defines the symbols recognized by the November 1985 draft proposal of the ANSI C standard. The local version of <stdio.h> defines many more symbols for use by local I/O routines.
Whenever LINT finds an #include directive of the form
#include <filename>
in a C source file, LINT must decide whether to use the standard or local version of the file. By default, LINT uses the local version. However, if you specify "-Local", LINT will use the standard version instead. Since the standard version only defines standard symbols, "-Local" will often result in more warning diagnostics.
The "-Local" option may not catch every local reference. For example, the standard version of <stdio.h> must include a definition for the FILE type. However, there is no standard statement of how this symbol should be defined. The designers of LINT therefore had to make up their own definition of FILE for the standard version of <stdio.h>, and to avoid vast confusion, they used the local definition. If a program is written to make use of special characteristics of the local FILE (e.g. if the program knows FILE is a structure, and references fields inside the structure by name), the code will be non-portable but LINT will not be able to detect the problem.
Copyright © 1996, Thinkage Ltd.