3. Standardization Efforts

All standards have a good side and an evil side. Due to the nature of this document, we are forced to focus our attention on the latter.

The American National Standards Institute (ANSI) has recently approved of a standard for the C programming language [13]. The Standard concentrates on the syntax and semantics of the language and specifies a minimum environment (the name and contents of some header files and the specification of some run-time library functions).

Copies of the ANSI C Standard (ANSI X3.159-1989) can be obtained from the following address:

	American National Standards Institute
	Sales Department
	1430 Broadway
	New York, NY 10018
	(Voice) (212) 642-4900
	(Fax) (212) 302-1286

3.1. ANSI C

3.1.1. Translation Limits

We first bring to the reader's attention the fact that the Standard states some environmental limits. These limits are lower bounds, meaning that a correct (compliant) compiler may refuse to compile an otherwise-correct program that exceeds one of those limits. (3)

Below are the limits that we judge to be the most important. The ones related to the preprocessor are listed first.

• 8 nesting levels of conditional inclusion.

• 8~nesting levels for #included files.

• 32 nesting levels of parenthesized expressions within a full expression. This will probably occur when using macros.

• 1024 macro identifiers simultaneously. Can happen if one includes too many header files.

• 509 characters in a logical source line. This is a serious restriction if it applies after preprocessing. Since a macro expansion always results in one line, this affects the maximum size of a macro. It is unclear what the Standard means by a logical source line in this context and in most implementations this limit will probably apply before macro expansion.

• 6 significant initial characters in an external identifier. Usually this constraint is imposed by the environment, e.g., the linker, and not by the compiler.

• 127 members in a single structure or union.

• 31 parameters in one function call. This may cause trouble with functions that accept a variable number of arguments. Therefore, it is advisable that when designing such functions that either the number of parameters be kept within reasonable bounds or that alternative interfaces be supplied, e.g., using arrays.

It is really unfortunate that some of these limits may force a programmer to code in a less elegant way. We are of the opinion that the remaining limits stated in the Standard can usually be obeyed if one follows "good" programming practices.

However, these limits may break programs that generate C code such as compiler-compilers and many C++ compilers.

3.1.2. Unspecified and Undefined Behavior

The following are examples of unspecified and undefined behavior:

1. The order in which the function designator and the arguments in a function call are evaluated.

2. The order in which the preprocessor concatenation operators # and ## are evaluated during macro substitution.

3. The representation of floating-point types.

4. An identifier is used that is not visible in the current scope.

5. A pointer is converted to something other than an integral or pointer type.

The list is long. One of the main reasons for explicitly defining what is not covered by the Standard is to allow the implementor of the C environment to make use of the most efficient alternative.

3.2. POSIX

The objective of the POSIX working group P1003.1 is to define a common interface for Unix. Granted, the ANSI C standard does specify the contents of some header files and the behavior of some library functions but it falls short of defining a useful environment. This is the task of P1003.1.

We do not know how far P1003.1 addresses the problems presented in this document as at the moment we lack proper documentation. Hopefully, this will be corrected in a future release of this document.

3. Maybe there are people out there who still write compilers in FORTRAN after all...

contents

Introduction

Preprocessors