The storage-class-specifier indicates linkage and storage duration. These attributes are discussed in “Disambiguating Names”. Storage-class specifiers have the form:

The typedef specifier does not reserve storage and is called a storage class specifier only for syntactic convenience. See “typedef” for more information.

At most one storage-class specifier can appear in a declaration. If the storage-class-specifier is missing from a declaration, it is assumed to be extern unless the declaration is of an object and occurs inside a function, in which case it is assumed to be auto. (See “Changes in Disambiguating Identifiers” for further details.)

Identifiers declared within a function with the storage class extern must have an external definition (see Chapter 10, “External Definitions”) somewhere outside the function in which they are declared.

Identifiers declared with the storage class static have static storage duration, and either internal linkage (if declared outside a function) or no linkage (if declared inside a function). If the identifiers are initialized, the initialization is performed once before the beginning of execution. If no explicit initialization is performed, static objects are implicitly initialized to zero.

A register declaration is an auto declaration, with a hint to the compiler that the objects declared will be heavily used. Whether the object is actually placed in fast storage is implementation-defined. You cannot take the address of any part of an object declared with the register specifier.

Type specifiers are listed below. The syntax is:

The following list enumerates all valid combinations of type specifiers. These combinations are organized into a number of sets, each set made up of one line. The arrangement of the type specifiers appearing in any combination below can be altered without effect. The type specifiers in each set are equivalent in all implementations.

In traditional C, the type long float is allowed and equivalent to double; its use is not recommended. It elicits a warning if you're not in –cckr mode. Use of the type long double is not recommended in traditional C.

---

Note: long long is not a valid ANSI C type, so a warning appears for every occurrence of it in the source program text in –ansi and –ansiposix modes.

---

Specifiers for structures, unions, and enumerations are discussed in “Structure and Union Declarations” and “Enumeration Declarations”. Declarations with typedef names are discussed in “typedef”.

A structure is an object consisting of a sequence of named members. Each member can have any type. A union is an object that can, at a given time, contain any one of several members. Structure and union specifiers have the same form. The syntax is:

The struct-decl-list is a sequence of declarations for the members of the structure or union. The syntax is:

In the usual case, a struct-declarator is just a declarator for a member of a structure or union. A structure member can also consist of a specified number of bits. Such a member is also called a bitfield. Its length, a non-negative constant expression, is separated from the field name by a colon. “Bitfields” are discussed at the end of this section.

The syntax for struct-declarator is:

A struct or union cannot contain a member with incomplete or function type, or that is an instance of itself. It can, however, contain a member that is a pointer to an instance of itself.

Within a structure, the objects declared have addresses that increase as the declarations are read left to right. Each non-field member of a structure begins on an addressing boundary appropriate to its type; therefore, there may be unnamed holes in a structure.

A union can be thought of as a structure whose members all begin at offset 0 and whose size is sufficient to contain any of its members. At most, one of the members can be stored in a union at any time.

A structure or union specifier of the second form declares the identifier to be the structure tag (or union tag) of the structure specified by the list. This type of specifier is one of

A subsequent declaration can use the third form of specifier, one of

Structure tags allow definition of self-referential structures. Structure tags also permit the long part of the declaration to be given once and used several times.

The third form of a structure or union specifier can be used prior to a declaration that gives the complete specification of the structure or union in situations in which the size of the structure or union is unnecessary. The size is unnecessary in two situations: when a pointer to a structure or union is being declared and when a typedef name is declared to be a synonym for a structure or union. This, for example, allows the declaration of a pair of structures that contain pointers to each other.

The names of members of each struct or union have their own name space, and do not conflict with each other or with ordinary variables. A particular member name cannot be used twice in the same structure, but it can be used in several different structures in the same scope. Names that are used for tags reside in a single name space. They do not conflict with other names or with names used for tags in an enclosing scope. This tag name space, however, consists of tag names used for all struct, union, or enum declarations. Thus the tag name of an enum may conflict with the tag name of a struct in the same scope. (See “Disambiguating Names”.)

A simple but important example of a structure declaration is the following binary tree structure:

struct tnode {
char tword[20];
int count;
struct tnode *left;
struct tnode *right; 
}; 

This structure contains an array of 20 characters, an integer, and two pointers to instances of itself. Once this declaration has been given, the declaration declares s to be a structure of the given sort and sp to be a pointer to a structure of the given sort. For example:

struct tnode s, *sp; 

With these declarations, the expression sp->count refers to the count field of the structure to which sp points. The expression s.left refers to the left subtree pointer of the structure s. The expression s.right->tword[0] refers to the first character of the tword member of the right subtree of s.

A structure member can consist of a specified number of bits, called a bitfield. Bitfields should be of type int, signed int, or unsigned int in strict ANSI C mode. Silicon Graphics allows bitfields of any integral type, but warn for non-int types in –ansi and –ansiposix modes.

The default type of field members is int, but whether it is signed or unsigned int is defined by the implementation. It is thus wise to specify the signedness of bitfields when they are declared. In this implementation, the default type of a bitfield is signed.

The constant-expression that denotes the width of the bitfield must have a value no greater than the width, in bits, of the type of the bitfield. An implementation can allocate any addressable storage unit (referred to in this discussion as simply a “unit”) large enough to hold a bitfield. If an adjacent bitfield will not fit in the remainder of the unit, whether a unit is allocated for it or bitfields are allowed to span units is implementation-defined. The ordering of the bits within a unit is also implementation-defined.

A bitfield with no declarator, just a colon and a width, indicates an unnamed field useful for padding. As a special case, a field with a width of zero, which cannot have a declarator, specifies alignment of the next field at the next unit boundary.

These implementation-defined characteristics make the use of bitfields inherently nonportable, particularly if they are used in situations—in a union, for example—where the underlying object may be accessed by another data type.

The first bitfield encountered in a struct is not necessarily allocated on a unit boundary and is packed into the current unit, if possible. A bitfield cannot span a unit boundary. Bits for bitfields are allocated from left (most significant) to right.

In the 64-bit implementation, bitfields are packed into as small a unit as possible, where the smallest unit is 0 bytes in size and the largest unit is 8 bytes in size. The alignment requirements of the struct are influenced only by the units used to pack bitfields, not by the type of the bitfields. This is quite different from 32-bit mode, which is described next.

In the 32-bit implementation, the size of a unit for bitfields is equal to the size of the type of the bitfield that started the unit. A new unit is allocated when the alignment of the type of the next bitfield differs from the alignment of the current unit, even if the number of bits in the next bitfield would fit into the current unit. For example, if the current unit has char alignment and the next bitfield has type int, then a new int-sized unit is allocated.

In this implementation, for example, the following structure is two units in size:

struct {
   char c;
   int k:9,
        :12;
   signed int j:5;
} s;

The first unit consists of the char c in its eight bits. The alignment of an int differs from that of a char; hence, the next 24 bits are padding, followed by an int unit. The (signed) int bitfield k is in the most significant 9 bits of the int unit, followed by 12 pad bits and the 5 bits of the signed int j. The size of this struct is eight bytes.

There are no arrays of bitfields. Since the address-of operator, &, cannot be applied to bitfields, there are no pointers to bitfields.

Enumeration variables and constants have integral type. The syntax is:

The identifiers in an enum-list are declared as int constants and can appear wherever such constants are allowed. If no enumerators with = appear, then the values of the corresponding constants begin at 0 and increase by 1 as the declaration is read from left to right. An enumerator with = gives the associated identifier the value indicated; subsequent identifiers continue the progression from the assigned value. Note that the use of = may result in multiple enumeration constants having the same integral value, even though they are declared in the same enumeration declaration.

Enumerators are in the ordinary identifiers name space (see “Name Spaces”). Thus, an identifier used as an enumerator may conflict with identifiers used for objects, functions, and user-defined types in the same scope.

The role of the identifier in the enum-specifier is entirely analogous to that of the structure tag in a struct-specifier; it names a particular enumeration. For example:

enum color { chartreuse, burgundy, claret=20, winedark }; 
...
enum color *cp, col; 
...
col = claret; 
cp = &col; 
...
if (*cp == burgundy) ...  

This example makes color the enumeration-tag of a type describing various colors, and then declares cp as a pointer to an object of that type and col as an object of that type. The possible values are drawn from the set {0,1,20,21}. The tags of enumeration declarations are members of the single tag name space, and thus must be distinct from tags of struct and union declarations.

Type qualifiers have the syntax shown below:

The same type qualifier cannot appear more than once in the same specifier list either directly or indirectly (through typedefs). The value of an object declared with the const type qualifier is constant. It cannot be modified, although it can be initialized following the same rules as the initialization of any other object. (See the discussion in “Initialization.”) Implementations are free to allocate const objects, which are not also declared volatile, in read-only storage.

An object declared with the volatile type qualifier may be accessed in unknown ways or have unknown side effects. For example, a volatile object may be a special hardware register. Expressions referring to objects qualified as volatile must be evaluated strictly according to the semantics. When volatile objects are involved, an implementation is not free to perform optimizations that would otherwise be valid. At each sequence point, the value of all volatile objects must agree with that specified by the semantics.

If an array is specified with type qualifiers, the qualifiers are applied to the elements of the array. If a struct or union is qualified, the qualification applies to each member.

Two qualified types are compatible if they are identically qualified versions of compatible types. The order of qualifiers in a list has no effect on their semantics.

The syntax of pointers allows the specification of qualifiers that affect either the pointer itself or the underlying object. Qualified pointers are covered in “Pointer Declarators”.

Declarators have the syntax shown below:

Portions of the list above are reproduced in the sections following, along with expansions of their constituent parts. The grouping is the same as in expressions.

T D1 

T D1 

const long *ptr_to_const; 
long * const const_ptr; 
volatile int * const const_ptr_to_volatile; 

float fa[17], *afp[17]; 

static int x3d[3][5][7]; 

double foo(int *first, float second, ... ); 
int *fip(int a, long l, int (*ff)(float)); 

int i, *ip, f(), *fip(), (*pfi)(); 

In several contexts (for example, to specify type conversions explicitly by means of a cast, in a function prototype, and as an argument of sizeof), it is best to supply the name of a data type. This naming is accomplished using a “type name,” whose syntax is a declaration for an object of that type without the identifier. The syntax for type names is shown below:

The type-name created can be used as a synonym for the type that the omitted identifier would have. The syntax indicates that a set of empty parentheses in a type name is interpreted as function with no parameter information rather than as redundant parentheses surrounding the (omitted) identifier. Examples of type names are shown in Table 8-1.

It is not always necessary to specify both the storage class and the type of identifiers in a declaration. The storage class is supplied by the context in external definitions, and in declarations of formal parameters and structure members. Missing storage class specifiers appearing in declarations outside of functions are assumed to be extern (see “External Name Changes” for details). Missing type specifiers in this context are assumed to be int. In a declaration inside a function, if a type but no storage class is indicated, the identifier is assumed to be auto. An exception to the latter rule is made for functions because auto functions do not exist. If the type of an identifier is function returning <type>, it is implicitly declared to be extern.

In an expression, an identifier followed by a left parenthesis (indicating a function call) that is not already declared, is implicitly declared to be of type function returning int.

Declarations with the storage class specifier typedef do not define storage. A typedef has the syntax shown below:

Rather than becoming an object with the given type, an identifier appearing in a typedef declaration becomes a synonym for the type. For example:

int intarray[10]; 

If, in the above example, the int type specifier were preceded with typedef, the identifier declared as an object would instead be declared as a synonym for the array type. This can appear as shown below:

typedef int intarray[10]; 

This example could be used as if it were a basic type. For example:

intarray ia;

After

typedef int MILES, *KLICKSP; 
typedef struct { 
double re, im; 
} 
complex; 

the constructions

MILES distance; 
extern KLICKSP metricp; 
complex z, *zp; 

are all legal declarations. The type of distance is int, that of metricp is pointer to int, and that of z is the specified structure. The zp is a pointer to such a structure.

The typedef does not introduce brand-new types, only synonyms for types that could be specified in another way. Thus, in the example above, distance is considered to have exactly the same type as any other int object.

A declaration of an object or of an array of unknown size can specify an initial value for the identifier being declared. The initializer is preceded by = and consists of an expression or a list of values enclosed in nested braces.

There cannot be more initializers than there are objects to be initialized. All the expressions in an initializer for an object of static storage duration must be constant expressions (see “Primary Expressions”.) Objects with automatic storage duration can be initialized by arbitrary expressions involving constants and previously declared variables and functions, except for aggregate initialization, which can only include constant expressions.

Identifiers declared with block scope and either external or internal linkage (that is, objects declared in a function with the storage-class specifier extern) cannot be initialized.

Variables of static storage duration that are not explicitly initialized are implicitly initialized to zero. The value of automatic and register variables that are not explicitly initialized is undefined.

When an initializer applies to a scalar (a pointer or an object of arithmetic type; see “Derived Types”), it consists of a single expression, perhaps in braces. The initial value of the object is taken from the expression. With the exception of type qualifiers associated with the scalar, which are ignored during the initialization, the same conversions as for assignment are performed.

int x[] = { 1, 3, 5 }; 

float y[4][3] = 
{
	{ 1, 3, 5 },
	{ 2, 4, 6 },
	{ 3, 5, 7 }, 
}; 

float y[4][3] = 
{
	1, 3, 5, 2, 4, 6, 3, 5, 7 
}; 

float y[4][3] = {

	{ 1 }, { 2 }, { 3 }, { 4 } 
}; 

union dc_u {
	double d;
	char *cptr; 
}; 

union dc_u dc0 = { 4.0 };

char msg[] = "Syntax error on line %s\n";