| Previous | Contents | Index |
The actual order in which expressions are evaluated is not specified for most of the operators in C. Because this sequence of evaluation is determined within the compiler depending on context, some unexpected results may occur when using certain operators. These unexpected results are caused by side effects.
Any operation that affects an operand's storage has a side effect. Side effects can be deliberately induced by the programmer to produce a desired result; in fact, the assignment operator depends on the side effect of altered storage to do its job. C guarantees that all side effects of a given expression will be completed by the next sequence point in the program. Sequence points are checkpoints in the program at which the compiler ensures that operations in an expression are concluded.
The most important sequence point is the semicolon marking the end of a statement. All expressions and their side effects are completely evaluated when the semicolon is reached. Other sequence points are as follows:
These operations do guarantee the order, or sequence, of evaluation (expr1), expr2, and expr3 are expressions). For each of these operators, the evaluation of expression expr1 is guaranteed to occur before the evaluation of expression expr2 (or expr3, in the case of the conditional expression).
Relying on the execution order of side effects, when none is guaranteed, is a risky practice because results are inconsistent and not portable. Undesirable side effects usually occur when the same data object is used in two or more places in the same expression, where at least one use produces a side effect. For example, the following code fragment produces inconsistent results because the order of evaluation of operands to the assignment operator is undefined.
int x[4] = { 0, 0, 0, 0 };
int i = 1;
x[i] = i++;
|
If the increment of i occurs before the subscript is evaluated, the value of x[2] is 1. If the subscript is evaluated first, the value of x[1] is 1.
A function call also has side effects. In the following example, the order in which f1(y) and f2(z) are called is undefined:
int y = 0;
int z = 0;
int x = 0;
int f1(int s)
{
printf ("Now in f1\n");
y += 7; /* Storage of y affected */
return y;
}
int f2(int t)
{
printf ("Now in f2\n");
z += 3; /* Storage of z affected */
return z;
}
main ()
{
x = f1(y) + f2(z); /* Undefined calling order */
}
|
The
printf
functions can be executed in any order even though the value of
x
will always be 10.
2.6 Incomplete Type
An identifier can be initially declared as having an incomplete type. An incomplete type declaration describes the object, but lacks the information needed to determine the object's size. For example, a declaration of an array of unknown size is an incomplete type declaration:
extern int x[]; |
The incomplete type may be completed in a subsequent declaration. Incomplete types are most commonly used when forward referencing arrays, structures, and unions. ( Section 2.12 discusses forward references.) An object of an aggregate type cannot contain a member of an incomplete type; therefore, an aggregate object (a structure or array member) cannot contain itself, because the aggregate type is not complete until the end of its declaration. The following example shows how an incomplete structure type is declared and later completed:
struct s
{ struct t *pt }; /* Incomplete structure declaration */
.
.
.
struct t
{ int a;
float *ps }; /* Completion of structure t */
|
The
void
type is a special case of an incomplete type. It is an incomplete type
that cannot be completed, and is used to signify that a function
returns no value. Section 3.5 has more information on the
void
type.
2.7 Compatible and Composite Types
Compatibility between types refers to the similarity of two types to each other. Type compatibility is important during type conversions and operations. All valid declarations in the same scope that refer to the same object or function must have compatible types. Two types are compatible if they fit any of the following categories:
int tree (int);
int tree1 (char);
int tree2 (x)
char x; /* char promotes to int in old-style
function parameters, and so is
compatible with tree */
{
...
};
|
The following types, which may appear to be compatible, are not:
A composite type is constructed from two compatible types and is compatible with both of the two types. Composite types satisfy the following conditions:
Consider the following file-scope declarations:
int f(int (*) (), double (*) [3]); int f(int (*) (char *), double (*)[]); |
They result in the following composite type for the function:
int f(int (*) (char *), double (*)[3]); |
The previous composite type rules apply recursively to types derived
from composite types.
2.8 Linkage
Data objects and functions can be implicitly or explicitly assigned linkage. There are three kinds of linkage:
When more than one declaration of the same object or function is made, linkage is made. The linked declarations can be in the same scope or in different scopes. Externally linked objects are available to any function in any compilation unit used to create the executable file. Internally linked objects are available only to the compilation unit in which the declarations appear.
The concept of linkage and the static and extern keywords are related, but not directly. Using the extern keyword in an object's declaration does not guarantee external linkage. The following rules determine the actual linkage of an object or function:
Identifiers other than data objects and functions have no linkage. An identifier declared as a function parameter also has no linkage.
The following examples show declarations with different linkages:
extern int x; /* External linkage */
static int y; /* Internal linkage */
register int z; /* Illegal storage-class declaration */
main () /* Functions default to external linkage */
{
int w; /* No linkage */
extern int x; /* External linkage */
extern int y; /* Internal linkage */
static int a; /* No linkage */
}
void func1 (int arg1) /* arg1 has no linkage */
{ }
|
In Compaq C, a message is issued if the same object is declared with both internal and external linkage.
A declaration of an identifier with file scope, no initializer, and either no storage-class specifier or the static storage-class specifier is a tentative definition. The tentative definition only applies if no other definition of the object appears in the compilation unit, in which case all tentative definitions for an object are treated as if there were only one file scope definition of the object, with an initializer of zero.
If a definition for a tentatively defined object is used later in the compilation unit, the tentative definition is treated as a redundant declaration of the object. If the declaration of an identifier for an object is a tentative definition and has internal linkage, the declared type cannot be an incomplete type. Section 2.8 discusses linkage.
The following are examples of tentative definitions:
int i1 = 1; /* Standard definition with external linkage */
int i4; /* Tentative definition with external linkage */
static int i5; /* Tentative definition with internal linkage */
int i1; /* Valid tentative definition, refers to previous */
/* i1 declaration */
|
Storage classes apply only to data objects and function parameters. However, storage class keywords in C are also used to affect the visibility of functions. Every data object and parameter used in a program has exactly one storage class, either assigned explicitly or by default. There are four storage classes:
An object's storage class determines its availability to the linker and its storage duration. An object with external or internal linkage, or with the storage-class specifier static , has static storage duration, which means that storage for the object is reserved and initialized to 0 only once, before main begins execution. An object with no linkage and without the storage-class specifier static has automatic storage duration; for such an object, storage is automatically allocated on entry to the block in which it is declared, and automatically deallocated on exiting from the block. An automatic object is not initialized.
When applied to functions, the storage-class specifier extern makes the function visible from other compilation units, and the storage-class specifier static makes the function visible only to other functions in the same compilation unit. For example:
static int tree(void); |
The following sections describe these storage classes.
2.10.1 The auto Class
The auto class specifies that storage for an object is created upon entry to the block defining the object, and destroyed when the block is exited. This class can be declared only at the beginning of a block, such as at the beginning of a function's body. For example:
auto int a; /* Illegal -- auto must be within a block */
main ()
{
auto int b; /* Valid auto declaration */
for (b = 0; b < 10; b++)
{
auto int a = b + a; /* Valid inner block declaration */
}
}
|
When you use an initializer with an auto object (see Section 4.2), the object is initialized each time it is created. Storage is reserved for the object whether the block containing the object is entered through normal processing of the block or through a jump statement into the block. However, if the block is entered through a jump statement, initialization of the object is not guaranteed, and if the object is a variable-length array, storage is not reserved.
The auto class is the default for objects with block scope. Objects with the auto class are not available to the linker.
Entering an enclosed block suspends, but does not end, execution of the enclosing block. Calling a function from within a block suspends, but does not end, execution of the block containing the call. Automatic objects with reserved storage maintain their storage in these cases. |
The register class identifies the assigned object as frequently used, suggesting to the compiler that the object should be assigned a register to minimize access time. register is never the default class; it must be explicitly specified.
The register class has the same storage duration as the auto class; that is, storage is created for a register object upon entry to the block defining the object, and destroyed when the block is exited.
The
register
class is the only storage class that can be explicitly specified for
function parameters.
The Compaq C compiler uses sophisticated register allocation
techniques that make the use of the
register
keyword unnecessary.
2.10.3 The static Class
The static class specifies that space for the identifier is maintained for the duration of the program. Static objects are not available to the linker. Therefore, another compilation unit can contain an identical declaration that refers to a different object.
A static object can be declared anywhere a declaration may appear in the program; it does not have to be at the beginning of a block, as with the auto class. If a data object is declared outside a function, it has static duration by default---it is initialized only once at the beginning of the program.
Expressions used to initialize
static
objects must be constant expressions. If the object with
static
storage duration is not explicitly initialized, every arithmetic member
of that object is initialized to 0, and every pointer member is
initialized as a null pointer constant. See Section 4.2 for more
information on initializing objects of various data types.
2.10.4 The extern Class
The
extern
class is the default class for objects with file scope.
Objects outside of any function (an external definition) receive the
extern
class storage unless explicitly assigned the
static
keyword in the declaration. The
extern
class specifies the same storage duration as
static
objects, but the object or function name is not hidden from
the linker. Using the
extern
keyword in a declaration results in external linkage in most cases (see
Section 2.8), and results in static duration of the object.
2.11 Storage-Class Modifiers
Compaq C provides the following storage-class modifiers:
__inline
__forceinline
__align
inline
The first three modifiers listed are recognized as valid keywords in all compiler modes on all platforms. They are in the namespace reserved to the C implementation, so it is not necessary to allow them to be treated as user-declared identifiers. They have the same effects on all platforms, except that on OpenVMS VAX systems, the __forceinline modifier does not cause any more inlining than the __inline modifier does.
The inline storage-class modifier is supported in relaxed ANSI C mode or if the /ACCEPT=C99_KEYWORDS (OPENVMS) or /ACCEPT=GCCINLINE (OPENVMS) qualifier is specified.
Compaq C for OpenVMS Systems also provides support for the storage-class modifiers noshare , readonly , and _align as VAX C keywords. For more information about these storage-class modifiers, see the Compaq C User's Guide for OpenVMS Systems (OPENVMS). |
You can use a storage-class specifier and a storage-class modifier in any order. Usually, the modifier is placed after the specifier in the source code. For example:
extern noshare int x; /* Or, equivalently...*/ int noshare extern x; |
However, placing the storage-class specifier anywhere other than first is obsolescent.
The following sections describe each of the Compaq C storage-class modifiers.
| Previous | Next | Contents | Index |