Consider the following C code, which results in a multiply defined function identifier ( my_max ):

$ type t.h int my_max (int x, int y) { if (x >= y) return (x); else return (y); } $ $ type a.c #include "t.h" main() { int a =1; int b=2; func1(); my_max(func1(a,b),20); } $ $ type b.c #include "t.h" void func1(int p1, int p2) { my_max(p1,p2); } $ $ link a,b %LINK-W-MULDEF, symbol MY_MAX multiply defined in module B file DISK$:[TEST.TMP]B.OBJ;4

One way around this problem is to define the function my_max with the keyword static :

static int my_max (int x, int y) { if (x >= y) return (x); else return (y); }

However, this means there is no globally visible my_max function but, rather, a copy of my_max for each module, each copy with a different address. Therefore, any function pointer comparisons would break.

The ISO C99 solution to this problem is the inline keyword. Adding inline to the header file t.h eliminates the MULDEF errors:

inline int my_max (int x, int y) { if (x >= y) return (x); else return (y); }

This type of function definition, like one specified with the __inline keyword, marks the function for potential inlining by the compiler. One difference, however, is that for an inline function, the compiler creates an inline auxiliary definition of the function, which is associated with the function being declared ( my_max in this example). The compiler is then free to do one of the following:

1. Call the auxiliary function.
2. Call the global function ( my_max ). This implies that there must be a global definition of any non- static inline function in one of the modules of the application.
3. Generate inlined code for the call to my_max .

There can be one and only one global definition for the inline function within an application. There can be one inline auxiliary definition per module, or many prototype declarations of the auxiliary function per module.

You can create a global inline definition by including in one of your modules (such as a.c in our example) a file-scope function declaration that:

1. Omits the inline keyword:

   #include "t.h" int my_max (int x, int y);

   
   OR

   #include "t.h" extern int my_max (int x, int y);

2. Or that specifies the extern storage class with the inline keyword:

   #include "t.h" extern inline int my_max (int x, int y);

Similar to the __inline storage-class modifier, the __forceinline storage-class modifier marks a function for inline expansion. However, using __forceinline on a function definition and prototype tells the compiler that it must substitute the code within the function definition for every call to that function. (With __inline , such substitution occurs at the discretion of the compiler.)

On OpenVMS VAX systems, the __forceinline storage-class modifier does not cause any more inlining to occur than the __inline modifier does.

Use the following form to designate a function for forced inline expansion:

__forceinline [type] function_definition

The compiler issues a warning if __forceinline is used in /STANDARD=PORTABLE mode, because this is an implementation-specific extension.

2.11.4 The __align Modifier

The __align storage-class modifier has the same semantic meaning as the _align keyword. The difference is that __align is a keyword in all compiler modes while _align is a keyword only in modes that recognize VAX C keywords. For new programs, using __align is recommended.

2.12 Forward References

Once declared, identifiers can be used freely. Using an identifier before its declaration is called a forward reference, and results in an error, except in the following cases:

• When a goto statement refers to a statement label before the label's declaration
• When a structure, union, or enumeration tag is used before it is declared

Here are some examples of valid and invalid forward references:

int a; main () { int b = c; /* Forward reference to c -- illegal */ int c = 10; glop x = 1; /* Forward reference to glop type -- illegal */ typedef int glop; goto test; /* Forward reference to statement label -- legal */ test: if (a > 0 ) b = TRUE; }

The following example shows the use of a structure tag in a forward reference:

struct s { struct t *pt }; /* Forward reference to structure t */ . /* (Note that the reference is preceded */ . /* by the struct keyword to resolve */ . /* potential ambiguity) */ struct t { struct s *ps };

2.13 Tags

Tags can be used with structures, unions, or enumerated types as a means of referring to the structure, union, or enumerated type elsewhere in the program. Once a tag is included in the declaration of a structure, union, or enumerated type, it can specify the declared structure, union, or enumerated type anywhere the declaration is visible.

The following code fragment shows the use of a structure tag, a union tag, and an enumerated type tag:

struct tnode { /* Initial declaration -- */ /* tnode is the structure tag */ int count; struct tnode *left, *right; /* tnode's members referring to tnode */ union datanode *p; /* forward reference to union type is declared below */ }; union datanode { /* Initial declaration -- */ /* datanode is the union tag */ int ival; float fval; char *cval; } q = {5}; enum color { red, blue, green };/* Initial declaration -- */ . /* color is the enumeration tag */ . . struct tnode x; /* tnode tag is used to declare x */ enum color z = blue; /* color tag declares z to be of type color; z is also initialized to blue */

As shown in the previous example, once a tag is declared it can be used to reference other structure, union, or enumerated type declarations in the same scope without fully redefining the object.

Tags can be used to form an incomplete type if they occur before the complete declaration of a structure or union. Incomplete types do not specify the size of the object; therefore, a tag introducing an incomplete type can only be used when the size of the object is not needed. To complete the type, another declaration of the tag in the same scope must define the object completely. The following example shows how a subsequent definition completes the incomplete declaration of the structure type s :

struct s; /* Tag s used in incomplete type declaration */ struct t { struct s *p; }; struct s { int i; };/* struct s definition completed */

Section 2.6 describes the concept of an incomplete type.

Consider the following declarations:

struct tag; union tag;

These declarations specify a structure or union type and declare a tag visible only within the scope of the declaration. The declaration specifies a new type distinct from any other type with the same tag in an enclosing scope (if any).

The following example shows the use of prior tag declarations to specify a pair of mutually-referential structures:

struct s1 { struct s2 *s2p; /*...*/ }; /* D1 */ struct s2 { struct s1 *s1p; /*...*/ }; /* D2 */

If s2 was declared as a tag in an enclosing scope, the declaration D1 would refer to s2 , not to the tag s2 declared in D2 . To eliminate this context sensitivity, the following declaration can be inserted ahead of D1 :

struct s2;

This declares a new tag s2 in the inner scope; the declaration D2 then completes the specification of the type.

2.14 lvalues and rvalues

An rvalue is the value of an expression, such as 2, or x + 3 , or (x + y) * (a - b) . rvalues are not allocated storage space. Examples of rvalues are the numbers 0 and 1 in the following code fragment:

if (x > 0) { y += 1; } x = *y; /* The value pointed to by y is assigned to x */

The identifiers x and y are objects with allocated storage. The pointer to y holds an lvalue.

An lvalue is an expression that describes the location of an object used in the program. The location of the object is the object's lvalue, and the object's rvalue is the value stored at the location described by the lvalue. The following operators always produce lvalues:

[] * ->

The dot operator ( . ) can, and usually does, produce an lvalue but it does not have to do so. For example, f().m is not an lvalue.

A modifiable lvalue is an lvalue that does not have array type, an incomplete type, a const -qualified type, or, if it is a structure or union, has no member with const -qualified type.

2.15 Name Spaces

Name spaces are identifier classifications based on the context of the identifier's use in the program. Name spaces allow the same identifier to simultaneously stand for an object, statement label, structure tag, union member, and enumeration constant. Simultaneous use of an identifier in the same scope for two different entities without ambiguity is possible only if the identifiers are in different name spaces. The context of the identifier's use resolves the ambiguity over which of the identically named entities is desired.

There are four different name spaces:

• Statement labels
• Structure, union, and enumeration tags
• Each structure and union member set
• Other identifiers (variables, functions, type definitions, and enumeration constants)

For example, the identifier flower can be used in one block to stand for both a variable and an enumeration tag, because variables and tags are in different name spaces. Subsequently, an inner block can redefine the variable flower without disturbing the enumeration tag flower . Therefore, when using the same identifier for various purposes, analyze the name space and scope rules governing the identifier. Section 2.3 presents the scope rules.

A structure, union, and enumeration member name can be common to each of these objects at the same time. The use of the structure, union, or enumeration name in the reference to the member resolves any ambiguity about which identifier is meant. However, the structure, union, or enumeration tag must be unique, since the tags of these three object types share the same name space.

2.16 Preprocessing

The translation of a C program occurs in several phases. Normally, when the compiler is started, several events occur before the actual compiler starts:

1. Trigraph sequences (if any) are replaced by single-character internal representations.
2. Each occurrence of a new-line character immediately preceded by a backslash character is deleted and the following line is spliced to form one logical line.
3. The source file is decomposed into preprocessing tokens and sequences of white-space characters. Each comment is replaced by one space character.
4. Preprocessing directives are executed and preprocessor macros are expanded. Files named in #include preprocessing directives are processed through these four steps recursively.
5. Each source character set member, and each escape sequence in character constants and string literals is converted to a member of the execution character set.
6. Adjacent character string literal tokens are concatenated and adjacent wide string literal tokens are concatenated.
7. The resulting stream of tokens is analyzed and translated.
8. The linking phase. All external object and function references are resolved. Library components are linked to satisfy external references to functions and objects not defined in the current compilation unit. All such linker output is collected into a program image.

The fourth step is called preprocessing, and is handled by a separate unit of the compiler. Each preprocessor directive appears on a line beginning with a pound sign (#); white space may precede the pound sign. These lines are syntactically independent from the rest of the C source file, and can appear anywhere in the source file. Preprocessor directive lines terminate at the end of the logical line.

It is possible to preprocess a source file without actually compiling the program (see your platform-specific Compaq C documentation for the available compiler options.) Chapter 8 discusses the preprocessing directives.

2.17 Type Names

In several contexts a type name can or must be specified without an identifier. For example, in a function prototype declaration, the parameters of the function can be declared only with a type name. Also, when casting an object from one type to another, a type name is required without an associated identifier. ( Section 6.4.6 has information on casting, and Section 5.5 has information on function prototypes.) This is accomplished using a type name, which is a declaration for a function or object which omits the identifier.

Table 2-1 shows examples of type names with the associated types they refer to.

Table 2-1 Type Name Examples

Construction	Type Name
int	int
int *	Pointer to int
int *[3]	Array of three pointers to int
int (*)[3]	Pointer to an array of three int s
int *()	Function with no parameter specification returning a pointer to int
int (*) (void)	Pointer to function with no parameters returning an int
int (*const []) (unsigned int, ...)	Array of an unspecified number of const pointers to functions, each with one parameter that has type unsigned int and an unspecified number of other parameters, returning an int

Table 2-1 also provides good examples of abstract declarators. An abstract declarator is a declarator without an identifier. The characters following the int type name form an abstract declarator in each case. The * , [ ] , and ( ) characters all indicate a declarator without naming a specific identifier.