United States

Compaq C

# Compaq C
Language Reference Manual

Previous | Contents | Index

# 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:

- Two types are compatible if they are the same.
- Two qualified types (see Section 3.7) are compatible if they are identically qualified and the two types, unqualified, are compatible. The order of the qualifiers in the type declaration does not matter.
- The types `short` , `signed short` , `short int` , and `signed short int` are the same and are compatible.
- The types `unsigned short` and `unsigned short int` are the same and are compatible.
- The types `int` , `signed` , and `signed int` are the same and are compatible.
- The types `unsigned` and `unsigned int` are the same and are compatible.
- The types `long` , `signed long` , `long int` , `signed long int` are the same and are compatible.
- The types `unsigned long` and `unsigned long int` are the same and are compatible.
- Two array types are compatible if they are of the same size and contain elements of compatible types. If one array has an unknown size, it is compatible with all other array types having compatible element types.
- Two unions or structures are compatible if they are declared in different compilation units, share the same members in the same order, and whose members have the same widths (including bit fields).
- Two enumerations are compatible if all members have the same values. All enumerated types are compatible with other enumerated types. An enumerated type is also compatible with the `signed int` type.
- Two pointer types are compatible if they are identically qualified and point to objects of compatible types.
- A function type declared using the old-style declaration (such as `int tree()` ) is compatible with another function type if the return types are compatible.
- A function type declared using the new prototype-style declaration (such as `int tree (int x)` ) is compatible with another function type declared with a function prototype if:
  - The return types are compatible.
  - The parameters agree in number (including an ellipsis if one is used).
  - The parameter types are compatible. For each parameter declared with a qualified type, its type for compatibility comparison is the unqualified version of the declared type.
- The function type of a prototype-style function declaration is compatible with the function type of an old-style function declaration if the return types are compatible, and if the old-style declaration is not a definition. (Different styles of function declarations are discussed in Chapter 5.) Otherwise, the function type of a prototype-style function declaration is compatible with the function type of an old-style function definition if all of the following conditions are met:
  - The return types of the two functions are compatible.
  - The number of parameters agree.
  - The prototype-style function declaration does not contain an ellipsis as a parameter.
  - The promoted types of the old-style parameters are compatible with the prototype-style parameter types. In the following example, the functions `tree` and `tree2` are compatible. `tree` and `tree1` are not compatible, and `tree1` and `tree2` are not compatible.

        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:

- `unsigned int` and `int` types are not compatible.
- `char` , `signed char` , and `unsigned char` types are not compatible.

Composite Type

A composite type is constructed from two compatible types and is compatible with both of the two types. Composite types satisfy the following conditions:

- If one type is an array of known size, the composite type is an array of that size. Otherwise, if one type is a variable-length array, the composite type is that type.
- If only one type is a function type with a prototype, the composite type is a function type with the parameter type list.
- If both types are functions types with prototypes, the type of each parameter in the composite parameter type list is the composite type of the corresponding parameters.

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:

- Internal linkage---a declaration referring to a data object or function declared in the same compilation unit, and not known outside the compilation unit.
- External linkage---a declaration referring to a definition of a data object or function known outside the compilation unit. The definition of the object also has external linkage.
- No linkage---a declaration declaring a unique data object.

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:

- An identifier explicitly specified with the `auto` or `register` storage class has no linkage.
- An identifier with block scope and the `extern` storage-class specification has linkage the same as any visible declaration of the same identifier with file scope. If no such declaration of the object or function is visible, then the object or function has external linkage.
- The declaration of functions defaults to external linkage. The only other storage class possible for a function is `static` , which must be specified explicitly, cannot be applied to a block scope function declaration, and results in internal linkage.
- The file scope declaration of a data object without an explicit storage class specification, or with the `extern` storage class specified, has external linkage.
- An identifier with file scope and the `static` storage class has internal linkage.
- An identifier with block scope and without the `extern` storage-class specification has no linkage.

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.

# 2.9 Tentative Definitions

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                                 */

# 2.10 Storage Classes

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:

- `auto`
- `register`
- `static`
- `extern`

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.

Note 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.

## 2.10.2 The register Class

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.

Note 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.

## 2.11.1 The __inline Modifier

The `__inline` storage-class modifier marks a function for inline expansion. Using `__inline` on a function definition and prototype tells the compiler that it can substitute the code within the function definition for every call to that function. Substitution occurs at the discretion of the compiler. The `__inline` storage-class modifier has the same effect as the `#pragma inline` preprocessor directive, except that `#pragma inline` attempts to provide inline expansion for all functions in a translation unit, rather than for selected functions (See your platform-specific Compaq C documentation for more information on `#pragma inline` ).

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

`__inline [type] function_definition`

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

Here is an example of using `__inline` :

    /* prototype */

    __inline int x (float y);

    /* definition */

    __inline int x (float y)

    {
       return (1.0);
    }

## 2.11.2 The inline Modifier

Similar to the `__inline` storage-class modifier, the `inline` storage-class modifier can be used as a declaration specifier in the declaration of a function.

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.

With static functions, `inline` has the same effect as applying `__inline` or `#pragma inline` to the function.

However, when `inline` is applied to a function with external linkage, besides allowing calls within that translation unit to be inlined, the `inline` semantics provide additional rules that also allow calls to the function to be inlined in other translation units or for the function to be called as an external function, at the compiler's discretion:

- If the `inline` keyword is used on a function declaration with external linkage, then the function must also be defined in the same translation unit.
- If all of the file-scope declarations of the function use the `inline` keyword but do not use the `extern` keyword, then the definition in that translation unit is called an inline auxiliary definition, and no externally-callable (global) definition is produced by that compilation unit.
  Otherwise, the compilation unit does produce an externally-callable definition.
- An `inline` auxiliary definition must not contain a definition of a modifiable object with static storage duration, and it must not refer to an identifier with internal linkage. These restrictions do not apply to the externally-callable definition.
- As usual, at most one compilation unit in an entire program can supply an externally-callable definition of a given function.
- Any call to a function with external linkage might be translated as a call to an external function, regardless of the presence of the `inline` qualifier. It follows from this and the previous point that any function with external linkage that is called must have exactly one externally-callable definition among all the compilation units of an entire program.
- The address of an `inline` function with external linkage is always computed as the address of the unique externally-callable definition, never the address of an inline definition.
- A call to an `inline` function made through a pointer to the externally-callable definition may still be inlined or translated as a call to an inline definition, if the compiler can determine the name of the function whose address was stored in the pointer.
- Without the `inline` keyword, a function definition in a header file produces MULDEF errors at link time, if the header file is included by more than one translation unit. Specifying `inline` on such a function definition is one way to eliminate these MULDEF errors. See the example ( Section 2.11.2.1).

Note This section describes the semantics of the C99 Standard `inline` keyword. The gcc compiler implements an inline function declaration specifier for functions with external linkage that gives similar capabilites to this C99 inline feature, but the details of usage are somewhat different---essentially, the combination of `extern` and `inline` keywords makes an inline definition, instead of the exclusive use of the `inline` keyword without the `extern` keyword. The /ACCEPT=[NO]GCCINLINE qualifier controls which variation of the feature is implemented.

Previous | Next | Contents | Index

privacy and legal statement