Introduction to CodeCheck
Every programmer has a distinctive style of writing. This style is an expression of many things: the programmer’s sense of æsthetics, the demands of speed and efficiency, the requirements of the customer, the needs of maintenance programmers, and the possibility that the program will need to be ported to another computer or translated into another language. Many of these elements of style require careful value judgments by the programmer or project leader. Once the stylistic requirements are clearly defined, CodeCheck can be an invaluable tool for monitoring each of these elements of program style.
The principal elements of good programming style are the requirements of æsthetics, maintenance, and portability. Fortunately, there are significant overlaps between these elements, as illustrated below. Can C programmers achieve a style that is at once portable, easily maintainable, and elegant? The answer is an emphatic “yes”, and CodeCheck can help any C or C++ programmer to develop his or her personal style towards this goal.
Figure 1: Overlap among the elements of good programming style.
There are several general principles that govern the overlap between these elements:
1. Code that is technically “portable” but not easily maintained is not truly portable. A nontrivial C program that is universally portable is a very rare animal indeed. There are so many dark and dusty corners in the syntax and semantics of C that universal portability is next to impossible. Therefore, programmers must make the purpose of their portable code evident — and this is the essence of maintainability.
2. Code that is elegant without being maintainable will have a short life. What good is elegant code if even its author cannot understand it one year later? The C grammar lends itself to code that is highly abstract and superficially elegant, especially in the area of character processing, but maintenance programmers may consider this style to be anything but æsthetically pleasing. What is wrong here is the equation of elegance with æsthetics: the two concepts are not identical.
3. Simplicity lies at the heart of portability, maintainability, and æsthetics. For reasons difficult to understand, many C programmers never learn this essential truth. Quite possibly the fault lies not in the language itself, but in the culture that has grown up around it. This culture seems to value complexity, density and abstractness over all other considerations, perhaps for the sheer fun of creating puzzles that others find impossible to solve. Whatever the reason, these values militate against clean, simple and understandable code.
Despite the C language’s reputation for portability, it is an unfortunate fact of life that an apparently flawless C program will usually fail when compiled with a different compiler, or under a different operating system, or on another type of computer. The reasons for this fact of life are many, but there are three principal forces at work which underlie almost all such problems.
1.2.1 Force #1: Language Parochialism
First, most programmers become thoroughly versed in only one implementation of C, on only one computer, under only one operating system. As they learn more about this programming environment, they unwittingly begin to use its many nonstandard features, and to take advantage of each of its quirks and foibles. These nonstandard features are typically concentrated in the lowest levels of operation: the preprocessor and the lexical analyzer of the compiler, the file management routines of the operating system, and the bit-manipulation instructions of the machine. Inexperienced programmers do not realize the extent to which computer languages are dependent on low-level conventions, and are wholly unaware of the implications of using nonstandard features. Unfortunately, these low-level nonstandard features tend to spawn an unending stream of the most amazingly mysterious bugs, often months or years after a program is first written.
1.2.2 Force #2: Programmer Machismo
The second force at work to make programs break is programmer machismo. Many programmers are young, smart, brash, fearless, and anxious to prove themselves to be wickedly clever. These are the programmers who write macros like
#define put(x,p) (--(p)->cnt>=0?(*(p)->ptr++=(x)):flush(x,p))
and think that by getting all this power on one single completely undocumented line they have achieved something special. What they have actually created is a maintenance nightmare for someone else. (This delightful example is due to Andrew Koenig, who dissects a slightly different version on page 80 of C Traps and Pitfalls).
1.2.3 Force #3: Compiler Drift
The third program-destroying force operates not on application programmers, but on compiler writers. This force is the almost irresistible temptation to include a new feature or language extension (nonstandard, naturally) that will ease the life of programmers and sell lots more compilers. The temptation to include these features is certainly not all bad, as it does generate an endless stream of new ideas for compilers, but it feeds directly into the other two forces. The result, if uncontrolled by tough project management and programmer self-discipline, is code that is neither maintainable nor portable.
1.2.4 CodeCheck can help!
For the C language programmer, to defend against all programming practices that can threaten portability or maintainability is a task requiring both an encyclopædic knowledge of C compilers and an almost superhuman level of self-discipline and attention to detail. For the project leader, the task of enforcing uniform standards for code structure and style is a severe test of the ability to read and critique great volumes of dense code. CodeCheck is designed to automate these tasks:
• The C programmer can use CodeCheck to review his or her code at the end of the day, and to identify questionable constructions that might have crept in. This daily CodeCheck program can implement many lint-like code checking operations, as well as checking for adherence to project style specifications.
• The project leader can use a different CodeCheck program on a weekly basis to verify the programmers’ adherence to the project style specifications, to quantify the amount of code produced, and to measure critical qualities of the code, e.g. density and complexity.
• Software contractors are frequently required to certify that their code conforms to published governmental and industrial standards for code complexity, among them the McCabe and Halstead measures. A CodeCheck program can be run at the conclusion of a project to document these particular measures, and many others too.
1.3.1 The Many Standards for the C Language
There seem to be no fewer than four “standards” for the C language, all of which are covered by CodeCheck. Figure 2 depicts the family tree for C standards, with the earliest version on top:
Figure 2: The Evolution of C Standards.
Each descendent of the original C has added significant extensions to the original language, while trying to remain true to the spirit of C.
◊ The K&R standard, as described in the first edition of Kernighan & Ritchie (1978). This is certainly the single most influential book in the history of C. The language was only loosely defined in this “standard,” however, and it lacks many of the popular features that are commonplace now (e.g. enumerated constants, prototypes, the void type). Although obsolete, there are still many K&R compilers in daily use around the world.
◊ The H&S standard, as described in the first edition of Harbison & Steele (1984). This was the first careful description of the K&R standard, with many modern extensions included (e.g. the enum and void types). The H&S standard represents a transitional phase between K&R and ANSI. Most pre-ANSI compilers in use today are best described as adhering to the H&S standard.
◊ The ANSI C standard, as defined by the American National Standards Institute and certified internationally as ISO/IEC 9899. This version represented a significant advance in precision over H&S. It also introduced several significant innovations (e.g. the preprocessor paste operator).
◊ The POSIX standard, as defined by the American National Standards Institute and certified internationally as ISO/IEC 9945. Part 1 of this standard includes and extends the ANSI C standard, and details the interface and behavior of a standard library of operating system services.
◊ The C++ 2.0 standard, as defined in “The Annotated C++ Reference Manual,” by Ellis and Stroustrup (1990). This book is the base document for an ANSI committee that is now developing an official standard for C++.
◊ The C++ 3.0 standard, as defined in “The C++ Programming Language Manual, 3rd Edition” by Bjarne Stroustrup (1997). This book is the base document of the pending ANSI C++ standard.
1.3.2 Two kinds of incompatibility
It is useful to break down a portation problem into two separate sources of incompatibility:
1. The source environment will invariably have a variety of idiosyncrasies which are common to no other, and which differ from the ostensible standard on which the environment is based. These differences are source portation problems.
2. The target environment will differ somewhat from the standard on which it was based. These differences are target portation problems.
The prepackaged CodeCheck rule files supplied by Abraxas with CodeCheck include several that address source and target portation problems. The source portation rule files have names that begin with “from”, as in “fromVax.cc” , which detects special keywords and other peculiarities that are found only on Vax C compilers. The target portation rule files have names that begin with “to”, as in “toKR.cc”, which tests for non-K&R syntax and keywords.
1.4 The Structure of CodeCheck
A CodeCheck program looks just like a very simple C program. Indeed, CodeCheck programs are written using a small subset of the C grammar, so anyone who can read C can also read CodeCheck. A CodeCheck program is, in fact, just a collection of if-statements (called “rules”) and variable declarations. The CodeCheck interpreter translates this collection of rules into pseudocode, which is used during the analysis of a C source to control the code checking operation.
Figure 5: Actions of the two components of CodeCheck.
To analyze a C source file, the user has only to specify the name of the C source file and the name of the CodeCheck program. The CodeCheck program will be compiled (if necessary), and then the C source file is analyzed in accordance with the CodeCheck rules. As depicted in Figure 5, CodeCheck has two logically separate components — the Code Analyzer and the Rule Compiler.
A brief bibliographic note
For those who are interested in referring to original sources, this manual makes many references to the C literature. These are given in a compressed format, as illustrated below. Details (title, etc.) are given in the bibliography.
HS84:182 means Harbison & Steele, 1984, page 182.
RJ88:52 means R. Jaeschke, 1988, page 52.
AK89:99 means A. Koenig, 1989, page 99.
CodeCheck is, in addition to all of its other functions, a sensitive bug detector, capable of identifying subtle bugs that many compilers miss. A program that compiles without error may still fail to pass CodeCheck’s rigorous cross-module syntactic and semantic analyses. There are two common reasons for this: (a) your program deviates from strict C in ways that your compiler permits, or (b) your program actually has a fault whose presence has gone unnoticed. The former case is a mild problem — it only implies a lack of portability — but the latter case may be quite serious.
To use CodeCheck as a bug-detector, use the rule file error.cc for an efficient “once-over-lightly” check of your project or any one of its source files. Even with no rule file at all, CodeCheck still performs a tremendous variety of unusual syntactic and semantic checks on its input. Given an entire project, for example, CodeCheck will compare external declarations and macro definitions across files and will advise if any discrepancies are found — regardless of how many or how few rules are included in the rule file. Please note that CodeCheck does not perform many of the standard semantic checks that all C and C++ compilers do. CodeCheck is designed to provide error checking that complements the checking performed by your compiler.
1.6 Predefined Macro Constants
CodeCheck has a predefined macro constant, CODECHECK, which is designed to permit conditional checking of C code. This macro constant has the value 100*(CodeCheck version number). Thus in CodeCheck version 8.02 this constant will have the value 802.
The CODECHECK macro can be used to hide code from CodeCheck, so that it will not be checked. This is extremely useful, for example, when in-line assembler code is intermixed with C code. Here is an example:
#ifndef CODECHECK
•••
••• /* Code to be hidden from CodeCheck */
•••
#endif
The lint macro can be used in exactly the same way. CodeCheck predefines this macro with the value 2.
CodeCheck also has another predefined macro constant BETA, for a version in format x.xxBy, BETA has value of y. For a version in format x.xx, the value of BETA is 0. Combined with macro CODECHECK, you can distinguish different minor releases.
Depending on the specific environment for which it is implemented, CodeCheck will predefine certain additional macro constants. These constants (as of CodeCheck version 8.02 ) are listed in the following table. See the update notes that accompany CodeCheck for the latest additions and changes. The table of macros is organized by operating system and compiler. Any of these may be changed by the user on the command line (using the –D or –U options) or from within rules (using the CodeCheck define and undefine functions).
Constant Value Comment
CODECHECK 802 Major Rev 802
BETA 3 Minor Rev 3
lint 2
__STDC__ 1 Option -k2 only.
__STDC__ 0 Except option -k2.
__cplusplus 1 C++ only (-k4 through –k9).
cplusplus 1 C++ only (-k4 through –k9).
__FILE__ <file name>
__LINE__ <line number>
__DATE__ <date>
__TIME__ <time>
Unix Operating System
unix 1
__unix 1
Constant Value Comment
DOS Operating System
MSDOS 1
M_I386 1
M_I86 1
M_I86LM 1
__386__ 1
__I386__ 1
__MSDOS__ 1
__LARGE__ 1 Except option -k7 or -k11
__BORLANDC 0x0500 Except option -k7 or -k11
__TURBOC__ 0x0500 Except option -k7 or -k11
_WIN32 1
OS/2 Operating System
__OS2__ 1
__FLAT__ 1
__IBMC__ 200 Except option -k6
__IBMCPP__ 200 Option -k4 only
__32BIT__ 1 Except option -k6
_M_I386 1 Except option -k6
NT Operating System
i386 1
MSDOS 1
_M_IX86 300
_MSDOS 1
_X86_ 1
_WIN32 1
VMS Operating System
vax 1
vms 1
vaxc 1
vax11c 1
VAX 1
VMS 1
VAXC 1
CC$gfloat 1
CC$parallel 1
Macintosh Operating System
applec 1
MC68000 1
mc68000 1
m68k 1
macintosh 1
Borland C++
__BCPLUSPLUS__ 0x0340
__TCPLUSPLUS__ 0x0340
__CDECL__ 1
_Windows 1
Constant Value Comment
Borland C++ continued:
__TEMPLATES__ 1
wchar_t short
Microsoft C++
__single_inheritance Expands to nothing.
__multiple_inheritance Expands to nothing.
__virtual_inheritance Expands to nothing.
_M_I86 1 Except Windows NT.
_M_I86LM 1 Except Windows NT.
_M_IX86 300
_MSC_VER 1200
_MSDOS 1
_X86_ 300
i386 1
MSDOS 1
_WIN32 1
Metaware High C
__HIGHC__ 1
Symantec C++
__SC__ 700
IBM Visual Age C++
__IBMCPP__ 350
Metrowerks CodeWarrior
__MWERKS__ 1
Debugging your source code with the CodeCheck preprocessor can be greatly enhanced by using the "-D?" switch, which will display the current state of CodeCheck internal symbol table for the pre-processor. If a particular intrinsic definition is non-desirable then the "-U" switch can be used to undefine the macro.
The CodeCheck product does not include the C/C++ system header files ( stdio.h, iostream.hpp, … ). These must be obtained from your compiler vendor, e.g. if source code to be analyzed by CodeCheck explicitly references stdio.h ( #include <stdio.h> ), then that header file must be available for CodeCheck to analyze. In summary for CodeCheck to analyze source code, all parts of the entire project to be analyzed must be present in order for the analysis to be successful.
Chapter 3: Checking Types
This section describes how to use CodeCheck to analyze type information with CodeCheck rules. These techniques are necessary for those who wish to write their own CodeCheck rules which detect conditions that depend on type information.
The ability to detect and analyze type information in declarations has been a part of CodeCheck since version 4.03. However, the ability to detect and analyze type information within executable code is relatively new to CodeCheck, having been introduced for C in version 5.04, and for C++ in version 5.05. Please refer to the CodeCheck Reference Manual for the exact definitions of the CodeCheck variable and functions mentioned in this chapter, and the Abraxas Technical Note ( www.abraxas-software.com/TechNotes.html ) series for recent changes and enhancements.
There are five broad categories of type-related rules that CodeCheck can enforce. Rules can be written that detect:
1. a declaration of any specified type,
2. a cast to or from any specified type,
3. an implicit type conversion to or from any specified type,
4. use of a variable or function of any specified type,
5. use of an operand of any specified type for any specified operator.
In addition, CodeCheck automatically checks function argument types for compatibility with the prototype for the function called, if one is in scope, and also checks the function return value for compatibility with the declared function return type.
3.1 How to Analyze a Type Declaration
Types in C and C++ are either simple or complex. A simple type consists of an unmodified base type, e.g. int or float, with possible qualifiers such as const, volatile, near, far, huge, export, etc. A complex type has a simple type as its base, and in addition has one or more additional levels, e.g. pointer to…, array of…, function returning…, or reference to… (the latter is allowed only in C++ and a few nonstandard C dialects). Each of these levels may have also have qualifiers (e.g. const, pascal, interrupt, etc.).
When an identifier is declared, CodeCheck set the variable dcl_levels to the number of levels in the type. Thus for simple variables dcl_levels will be zero. CodeCheck sets the variable dcl_base to an integer that identifies the base type of the identifier. The possible values of dcl_base are defined as manifest constants in the CodeCheck header file check.cch, which should be included in every rule file that makes use of type-checking services. Here are the first five base types from check.cch:
#define VOID_TYPE 1
#define CHAR_TYPE 2
#define SHORT_TYPE 3
#define INT_TYPE 4
#define LONG_TYPE 5
As an example of the use of these CodeCheck variables to detect a specified type, here is a rule that will issue a message whenever a simple variable of type char is declared:
if ( dcl_base == CHAR_TYPE )
if ( dcl_levels == 0 )
warn( 1234, "Variable %s is a char.", dcl_name() );
When the type in a declaration is complex, the function dcl_level() returns an integer that identifies the kind of each level. Here is an example rule that prints out the type of every global or local identifier that is declared:
int i, kind;
if ( dcl_global || dcl_local )
{
printf( "Variable %s: ", dcl_name() );
i = 0;
while ( i < dcl_levels )
{
kind = dcl_level( i++ );
switch( kind )
{
case ARRAY:
printf( "array of " );
break;
case POINTER:
printf( "pointer to " );
break;
case REFERENCE:
printf( "reference to " );
break;
case FUNCTION:
printf( "function() returning " );
break;
}
}
printf( "%s\n", dcl_base_name() );
}
The manifest constants ARRAY, POINTER, REFERENCE, and FUNCTION are defined in check.cch. In addition to dcl_level(), this rule also used the functions dcl_name() and dcl_base_name(). These functions return the declarator name and the name of the base type of the declaration, respectively. The variables in the trigger for this rule are dcl_global and dcl_local, which CodeCheck sets to 1 when a global or local identifier is declared, respectively. (In this context “global” means file scope and external linkage, while “local” means function or block scope.)
To obtain the type qualifiers for each level of a type, including the base type level, use the function dcl_level_flags(). This function takes as its argument the level, just like dcl_level(), and returns an integer that has a bit set for each qualifier present. The header file check.cch contains manifest constants that can be used as masks to obtain each of these qualifier flags. For example, the following rule can be used to detect declarations in which the first level has the const qualifier:
if ( dcl_level_flags(0) & CONST_FLAG )
warn( 1234, "%s has been declared constant.", dcl_name() );
There are many other declarator variables and functions that are useful for analyzing declared types — refer to the CodeCheck Reference Manual for details.
3.2 How to Determine the Type of an Identifier
The CodeCheck variables and functions for determining the type of an identifier that is used within executable code are almost identical to those for declarations, except that they carry the prefix idn_ instead of dcl_.
The function idn_filename() and the variable idn_line can be used to determine the location (i.e. file name and line number) of the declaration that is currently in scope for the identifier as it is used in the executable code.
The variables idn_global, idn_local, idn_member, and idn_parameter also resemble their dcl_ counterparts: they are used to determine whether the identifier has global, local, or class scope, or is a function parameter, respectively.
3.3 How to Determine the Type of an Operand
The CodeCheck variables and functions for determining the types of all the operands of executable operators are similar to their counterparts for declarations and identifiers. The major difference is that they require an additional argument which specifies which operand to describe.
Operators may be unary (one operand, e.g. ~ ), binary (two operands, e.g. += ), or ternary (three operands, e.g. ?: ). Functions have as many operands as they have arguments. Whenever an executable operator is encountered, CodeCheck sets the appropriate op_ variables to indicate which operator was found, and sets op_operands to the number of operands taken by this operator.
The CodeCheck functions op_base(), op_levels(), op_level(), and op_level_flags() differ from their declarator and identifier counterparts in only one way: their first argument specifies which operand is to be described. The operands are indexed from right to left. Thus the rightmost operand is the operand 1, while the leftmost operand is the last (index given by op_operands). For example, in the expression x = a + b the first operand for op_add is b, and the second is a. For the operator op_assign, the first operand is the result of (a+b), and the second is x.
In the special case of the cast operator, the first operand is the type of the value to be cast, while the second operand is the result type after the cast has been performed. Here is an example rule that detects every cast of a pointer to a struct XYZ, to any result type, i.e. a cast that looks like (struct XYZ *):
if ( op_cast )
{
if ( (op_levels(1) == 2) &&
(op_level(1,0) == POINTER &&
(op_base(1) == STRUCT_TYPE) &&
(strcmp(op_base_name(1),"XYZ") == 0) )
warn( 1234, "Cast from (struct XYZ *) to anything." );
}
3.4 How to Detect Implicit Type Conversions
Implicit type conversions can happen in three different contexts. First, when a value of one type is assigned to a value of another type, without an explicit cast, then an implicit type conversion takes place. Second, when the type of an argument that is passed to a function differs from the type of the formal parameter in the prototype for the function, then it must be implicitly converted. Third, an implicit type conversion occurs when type of the value in a return statement differs from the return type of the function.
The CodeCheck functions used for determining the types involved in all implicit type conversions are the same functions as used for operators. However, to detect an implicit type conversion, one of the cnv_ variables must be used as the trigger in the rule. When one of these variables is set, then CodeCheck uses the op_ functions as though a cast operator were present for the conversion.
Here is an example rule that detects every implicit conversion of anything to a pointer to a struct XYZ:
if ( cnv_any_to_ptr || cnv_ptr_to_ptr )
{
if ( (op_levels(2) == 2) &&
(op_level(2,0) == POINTER) &&
(op_base(2) == STRUCT_TYPE) &&
(strcmp(op_base_name(2),"XYZ") == 0) )
warn( 1234, "Implicit conversion to (struct XYZ *)." );
}
Chapter 4: Portable Style
This section describes how to use CodeCheck to monitor style for portability. Many of the rules described here are based on internal corporate standards for C coding that have been made available to Abraxas Software, and also on the recommendations of two influential books: C Programming Guidelines, Second Edition, by Thomas Plum, and Portability and the C Language, by Rex Jaeschke.
The guidelines and recommendations found in these sources were designed primarily to enforce both portability and maintainability. In the subsections that follow, those guidelines that primarily affect program portability are presented. Each guideline is followed by a description of the relevant CodeCheck variables that can be used to construct corresponding CodeCheck rules.
4.1 Lexical Issues in Portability
4.1.1 Lexical Rules for Variable Names
C programmers have evolved a great variety of lexical guidelines for variables and their declarations. The guidelines reported here are specifically intended to ensure portability. Additional guidelines that are intended to improve maintainability may be found in Chapter 4.
1. Spell variable names in lower case only.
2. Names with external linkage must be unique in their first 6 characters.
3. Do not begin an identifier with an underscore character.
The predefined CodeCheck variables which are used to detect violations of the above guidelines are, respectively:
Variable Meaning
dcl_any_upper Set to 1 if an upper-case character is found in an identifier name when it is declared.
dcl_extern_ambig If two external identifiers have names that agree on the first 6 or more characters, regardless of case, then this variable is set to the number of consecutive characters on which they agree.
dcl_underscore Set to 1 if the name of a declared identifier begins with an underscore character.
4.1.2 Nonstandard Characters
Many C compilers allow the use of characters that are not in the standard C character set. Nonstandard characters are, by definition, not portable. The standard characters are (HS88:6):
a b c d e f g h i j k l m n o p q r s t u v w x y z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9
! # % ^ & * ( ) - _ + = ~ [ ] \ | ; : ' " { } , . < > / ?
blank newline backspace horizontal-tab
vertical-tab form-feed carriage-return
Recommendation: For general portability, do not use nonstandard characters. Note that the characters $ and @ are nonstandard. CodeCheck provides a predefined variable with which to detect nonstandard characters:
Variable Meaning
lex_nonstandard Whenever a character is found that is not in the standard C set, the value of this variable is set to the integer representation of the nonstandard.
To ignore nonstandard identifiers, call function skip_nonansi_ident().
Function Meaning
skip_nonansi_ident( char ) Skip non-ANSI identifiers beginning with '@','$' or '`'. Char parameter of this function specifies the character which leads the identifier. The value of the parameter only can be '@', '$' or '`'. The other characters have no effect for this function.
4.1.3 Trigraphs
Trigraphs are special 3-character sequences introduced in ANSI C. Trigraphs are significant as a portability issue only to the extent that older programs which unwittingly use trigraph sequences within literal strings will no longer compile correctly (RJ:28). ANSI C compilers translate trigraph sequences into their corresponding single ASCII characters at a very early stage in the lexical analysis phase of compilation. The trigraph sequences and their corresponding ASCII characters are:
trigraph meaning
??= #
??( [
??/ \
??) ]
??' ^
??< {
??! |
??> }
??- ~
Recommendation: Search old programs for the ?? symbol pair, and replace every occurrence with ?\?. Older compilers will simply ignore the backslash, while ANSI compilers will treat ?\? as a question mark followed by an escape sequence, thus recoding the string to ??. CodeCheck provides two predefined variables for identifying inadvertent trigraphs:
Variable Meaning
lex_trigraph Set to 1 if an ANSI trigraph is found.
lex_str_trigraph Set to 1 if a trigraph is found within a string literal.
4.1.4 Numeric Escape Codes
Numeric escape codes are permitted in C, but they are normally used to refer to control characters in the ASCII character set (HS84:25). Such numeric escape codes will cause a program to fail when it is compiled and used in a non-ASCII (e.g. EBCDIC) environment.
There is a potentially confusing aspect of hexadecimal escape sequences. Unlike octal sequences, which may have at most three digits, the ANSI C standard specifies that a hexadecimal escape sequence may have any number of digits. Thus the string literal "/xabcd" contains only one character (because a, b, c, and d are all valid hex digits).
Recommendation: Do not use numeric escape codes unless it is absolutely necessary. Carefully document the meaning of each such usage in the source code, and use a manifest constant (#define) to make its meaning apparent. CodeCheck provides two predefined variables for detecting numeric escape codes:
Variable Meaning
lex_hex_escape When a hexadecimal escape sequence is found, this variable is set to number of hexadecimal digits found.
lex_num_escape When a non-zero numeric escape sequence is found, the value of this variable is set to the value of the escape sequence.
lex_zero_escape When a zero escape sequence is found (e.g. \0, \00, \x0, \0x0), the value of this variable is set to 1 if the context is a character literal, or 2 if the context is a string literal.
4.1.7 Escape Sequences in Character and String Literals
An escape sequence within a character or string literal is signaled by the backslash character: \. The unrestricted use of escape sequences is a frequent source of portability problems.
1. For reasons that shall remain forever mysterious, many pre-ANSI compilers allow the digits 8 and 9 to appear within an octal escape sequence, as in \09. This usage has always been hopelessly confusing, has always been non-portable, and is now, fortunately, also ungrammatical.
2. Many pre-ANSI compilers do not support the hexadecimal escape sequence, as in \xA3. This usage is therefore not portable except among ANSI compilers. The hexadecimal escape sequence \0xA3 (with a zero appearing before the x) is even rarer, and is forbidden by ANSI.
3. In the K&R dialect of C the only defined escape characters are in this set:
\n \b \t \r \f \\ \" \'
In all other cases when a backslash is followed by a character, the backslash is ignored. The H&S dialect allows one more escape, \v (vertical tab). The, ANSI standard includes three further escape characters: \a (alert or bell), \x (hexadecimal), and \? (to disambiguate trigraphs). Thus pre-ANSI programs which rely on the backslash being ignored before the letters a, v, or x are no longer portable.
4. The empty character constant formed by two successive single quote marks ('') is not consistently interpreted by C compilers, and is not allowed by many. In particular, it is not always the same as the null character '\0'.
5. Many C compilers allow character constants to have more than one character. Even if all compilers did allow this usage, it would still be non-portable due to the infamous NUXI problem. (“NUXI” refers to the worst-case scrambling of the string “UNIX” that can result when porting encoding character strings).
To detect the above portability problems, CodeCheck provides the following six predefined variables:
Variable Meaning
lex_big_octal Set to 8 or 9, respectively, when a numeric escape sequence or octal integer contains the digits 8 or 9.
lex_hex_escape When a hexadecimal escape sequence is found, this variable is set to number of hexadecimal digits found.
lex_ansi_escape Set to 1 if an escape sequence contains one of the new ANSI escape characters: a, v, or ?.
lex_not_KR_escape Whenever an escape character is found that is not defined by K&R (i.e. \n, \b, \t, \r, \f, \\, \", \') then this variable is set to the integer representation of the character.
lex_char_empty Set to 1 if an empty character constant is found (e.g. ''). This variable does not flag the null character constant ('\0').
lex_char_long Set to 1 if a character constant is longer than one character.
4.1.8 System Variables
A useful convention has evolved within the C community in which identifiers that are defined and used by the system (i.e. variables used by the compiler, the linker, or standard system header files) are spelled with a leading underscore character. If programmers conform to this convention by never spelling an identifier in this way, then name conflicts are prevented. Unfortunately, some programmers are unaware of this convention, and may inadvertently spell an identifier with a leading underscore. Even if the program compiles without error, it will break as soon as it is compiled on another system that happens to use one of these names. This is, therefore, an obscure but significant portability problem.
Recommendation: Adhere to this convention religiously. Do not spell identifiers with a leading underscore character, unless you are writing system code. CodeCheck predefined variable:
Variable Meaning
dcl_underscore Set to 1 if an identifier begins with an underscore character.
4.1.9 The Numeric Constant Suffixes U, F, and L
The ANSI standard and some pre-ANSI compilers allow a suffix of U (for unsigned) or F (for float) on numeric constants, in precisely the same way that the suffix L (for long) is allowed in K&R C. Needless to say, this is not a portable usage among pre-ANSI compilers.
The suffix L is generally portable, except when it is used on a floating constant. Only some non-ANSI compilers recognize the long float type, so this is a non-portable use of the L suffix.
Recommendation: The new suffixes U and F solve many problems of numeric ambiguity, and should be used on the grounds that they increase program clarity and make maintenance easier. The cost in terms of lack of portability is substantially less than the benefit for program clarity.
CodeCheck provides four predefined variables for suffix detection:
Variable Meaning
lex_float Set to 1 if a numeric constant is found with the suffix 'F' or 'f'.
lex_long_float Set to 1 if a floating constant is found with the suffix 'L' or 'l'.
lex_suffix