The New C Standard (Excerpted material)

Transcription

1 The New C Standard (Excerpted material) An Economic and Cultural Derek M. Jones derek@knosof.co.uk Copyright Derek M. Jones. All rights reserved.

2 Structure and union members Structure and union members Constraints operator. first operand shall The first operand of the. operator shall have a qualified or unqualified structure or union type, and the second operand shall name a member of that type. The. operator effectively operates on the left operand to make its member names visible. The right operand indicates which one is to be accessed. Other Languages This notation is common to most languages that support some form of structure or union type. Cobol uses the keyword OF and reverses the order of the operands. Common Implementations The definition originally used in K&R allowed the right operand to belong to any visible structure or union type. This restricts member names to being unique; there was a single structure and union name space, not a separate one for each type. A member name was effectively treated as a synonym for a particular offset from a base address. An extension sometimes seen in translators [3] for freestanding environments is to define the behavior when the left operand has an integer type and the right operand is an integer constant. In this case the. operator returns the value of the bit indicated by its right operand from the value of the left operand. Other extensions, seen in both environments, include anonymous unions and even unnamed members. [7] In this case the right operand may be any member contained within the type of the left operand (translator documentation does not always specify the rules used to disambiguate cases where more than one member could be chosen) void Plan_9(void) 2 { 3 typedef struct lock { 4 int locked; 5 } Lock; 6 struct { 7 union { 8 int u_mem1; 9 float u_mem2; 10 }; /* Constraint violation, but supported in some implementations. */ 11 int s_mem2; 12 Lock; /* Constraint violation, but supported in some implementations. */ 13 } obj; obj.u_mem1=3; /* Access member without any intermediate identifiers. */ 16 obj.locked=4; 17 } The first operand of the -> operator shall have type pointer to qualified or unqualified structure or pointer to qualified or unqualified union, and the second operand shall name a member of the type pointed to. The -> operator is really a shorthand notation that allows (*p).mem to be written as p->mem. Because many structure members accesses occur via pointers this notational convenience makes for more readable source code v 1.1 January 30, 2008

3 Structure and union members 1031 Other Languages Many languages do not need to provide a shorthand notation covering this case. In those languages where the indirection operator appears to the right of the operand, member selection does not require parentheses. In Pascal, for instance, R.F selects the field F from the record R, while P_R^.F selects the field from the record pointed to by P_R. However, it might be asked why it is necessary to use a different operator just because the left operand has a pointer type. The language designers could have chosen to specify that an extra indirection is performed, if the left operand has a pointer type. The Ada language designers took this approach (to access all of a pointed-to object the reserved word all needs to be used). Semantics 1031 A postfix expression followed by the. operator and an identifier designates a member of a structure or union member selection object. Members designated using the. operator are at a translation time known offset from the base of the structure (members of unions always have an offset of zero). This translation-time information is available via the union members start same address offsetof macro. Other Languages Cobol and PL/1 support elliptical member references. One or more selection operators (and the corresponding member name) can be omitted, provided it is possible for a translator to uniquely determine a path to the specified member name. By allowing some selection operators to be omitted, a long chain of selections can be shortened (it is claimed that this improves readability). Cobol and Algol 68 use the reverse identifier order (e.g., name OF copper rather than copper.name). Coding Guidelines Structure or union types defined in system headers are special in that development projects rarely have any control over their contents. The members of structure and union types defined in these system headers can vary between vendors. An example of the different structure members seen in the same structure type is provided by the dirent structure. The POSIX.1 Standard [2] requires that this structure type include the members d_name and d_namelen. The Open Groups Single Unix Specification [8] goes further and requires that the member d_ino must also be present. Looking at the system header on Linux we find that it also includes the members d_off and d_type; that is 1 struct dirent { 2 ino_t d_ino; /* SUS */ 3 off_t d_off; /* Linux */ 4 unsigned char d_type; /* Linux */ 5 unsigned short int d_reclen; /* POSIX.1 */ 6 char d_name[256]; /* POSIX.1 */ 7 }; While developers cannot control the availability of members within structure types on different platforms, they can isolate their usage of those members that are vendor-specific. Encapsulating the use of specific members within functions or macro bodies is one solution. Most host development environments predefine a number of macros and these can be used as feature test macros by a development group. feature test macro January 30, 2008 v 1.1

4 Structure and union members Table : Number of member selection operators of the same object (number of dot selections is indicated down the left, and the number of indirect selections across the top). For instance, x.m1->m2 is counted as one occurrence of the dot selection operator with one instance of the indirect selection operator. Based on the translated form of this book s benchmark programs.. \ -> ,745 10, ,160 34,065 3, ,252 6, lvalue footnote 85 cast scalar or void type bit-field in expression The value is that of the named member DR283), and is an lvalue if the first expression is an lvalue. A member access that reads a value behaves the same as an access that reads from an ordinary identifier. The number of constructs whose result has a structure, or union, type that is not an lvalue has been reduced to one in C99. The cast operator does not return an lvalue, but its operand cannot be a structure or union type. The issue of members having a bit-field type is discussed elsewhere. Common Implementations The base address of file scope objects having a structure type may not be known until link-time. The offset of the member will then need to be added to this base address. Nearly all linkers support some kind of relocation information, in object files, needed to perform this addition at link-time. The alternative is to generate machine code to load the base address and add an offset to it, often a slower instruction (or even two instructions). Example struct s { 2 int m; 3 }; 4 5 void f(void) 6 { 7 int *p_i; 8 struct s l_s; 9 10 p_i = &(l_s.m); 11 /* 12 * A strictly conforming program can only cast an object having 13 * a structure type to exactly the same structure type. 14 */ 15 p_i = &(((struct s)l_s).m); /* Constraint violation, & not applied to an lvalue. */ 16 } struct qualified result qualified If the first expression has qualified type, the result has the so-qualified version of the type of the designated member. The qualifiers on the result type are the union of the set of type qualifiers on the two operands. Other Languages The logic of an outer qualifier applying to all the members of a structure or union applies to qualifiers followed in most programming languages v 1.1 January 30, 2008

5 Structure and union members 1034 Example 1 void f(void) 2 { 3 const struct { 4 const int mem_1; 5 int mem_2; 6 } x; 7 8 x.mem_1; /* Has type const int, not const const int */ 9 x.mem_2; /* Also has type const int */ 10 } Also see a C Standard example elsewhere EXAMPLE qualifiers 1034 A postfix expression followed by the -> operator and an identifier designates a member of a structure or union object. A consequence of the pointer dereference operator, *, being a prefix rather than a postfix operator and having a lower precedence than the member selection operator,., is that it is necessary to write (*p).mem to access a member of a pointed-to structure object. To provide a shorthand notation, the language designers could either have specified that one level of pointer indirection is automatically removed if the left operand of the. operator has pointer type (as Ada and Algol 68 do), or they could specify a new operator. They chose the latter approach, and the -> operator was created. C++ The C++ Standard specifies how the operator can be mapped to the dot (.) form and describes that operator only. If E1 has the type pointer to class X, then the expression E1->E2 is converted to the equivalent form (*(E1)).E2; the remainder of will address only the first option (dot) 59) p3 Common Implementations In this case the base address of the pointed-to object is not usually known until program execution, although the offset of the member from that address is known during translation. Processors invariably support a register+offset addressing mode, where the base address of an object (the address referenced by the left register + offset operand) has already been loaded into register. It is common for more than one member of the pointed-to object to be accessed within a sequence of statements and this base address value will compete with other frequently used values to be held in a register. The time taken to load a value from storage can be significant and processors use a variety of techniques to reduce this performance overhead. Walking tree-like data structures, using the -> operator, can result in cache poor locality of reference and make it difficult for a processor to know which storage locations to prefect data from. A study by Luk and Mowry [4] investigated translator-controlled prefetching schemes. Coding Guidelines The issues common to all forms of member access are discussed elsewhere. There is a difference between the use of the. and -> operators that can have coding guideline implications. Accessing the member of a nested structure type within one object can lead to a series of successive. operators being applied to the result of preceding. operators. In this case the sequence of operators is narrowing down a particular member within a larger object; the member selections are intermediate steps toward the access of a particular member. It is likely that different members will have different types and if an incorrect member appears in the selection chain, a diagnostic will be issued by a translator member selection January 30, 2008 v 1.1

6 Structure and union members The -> operator is often used to access members of a tree-like data structure whose nodes may have a variety of types and are independent objects. A sequence of -> operators represents a path to a particular node in this tree, relative to other nodes. The member selection path used to access a particular member is not limited to the depth of nesting of the structure types involved. To work out what the final node accessed represents, developers need to analyze the path used to reach it, where each node on the path is often a separate object. (An incorrect path is very unlikely to generate a diagnostic during translation) In many cases developers are not interested in the actual path itself, only what it represents. When there is a sequence of -> operators in the visible source code, developers need to deduce, or recognize, the algorithmic semantics of the operation sequence. This deduction can require significant developer cognitive resources. There are a number of techniques that might be used to reduce the total resources required, or reduce the peak load required. The following example illustrates the possibilities: 1 typedef struct TREE_NODE *TREE_PTR; 2 struct TREE_NODE { 3 int data; 4 TREE_PTR left, 5 right; 6 }; 7 8 #define LEFT_NODE(branch) ((branch)->left) 9 #define RIGHT_NODE(branch) ((branch)->right) 10 #define Get_Road_Num(node) ((node)->left->right->left.data) extern TREE_PTR root; void f(void) 15 { 16 int leaf_valu; 17 TREE_PTR temp_node_1, 18 temp_node_2, 19 destination_addr, 20 road_name; leaf_valu = root->left->right->left.data; 23 leaf_valu = ((root->left)->right)->left.data; 24 /* 25 * Break the access up into smaller chunks. Is the access 26 * above easier or harder to understand than the one below? 27 */ 28 temp_node_1 = root->left; 29 temp_node_2 = temp_node_1->right; 30 leaf_valu = temp_node_2->left.data; 31 /* 32 * If the intermediate identifier names had a name that suggested 33 * an association with what they represented, the effort needed, 34 * by developers, to create their own associations might be reduced. 35 */ 36 destination_addr = root->left; 37 road_name = destination_addr->right; 38 leaf_valu = road_name->left.data; 39 /* 40 * Does hiding the underlying access details, an indirection 41 * operator, make any difference? 42 */ 43 leaf_valu = LEFT_NODE(RIGHT_NODE(LEFT_NODE(root))).data; 44 /* 45 * The developer still has to deduce the meaning of the access from the path 46 * used. Why not hide the complete path behind a meaningful identifier? 47 */ 48 leaf_valu = Get_Road_Num(root); v 1.1 January 30, 2008

7 Structure and union members } Some of these issues also affect other operators. At the time of this writing there is insufficient experimental sequential nesting evidence to enable a meaningful cost/benefit analysis to be performed The value is that of the named member of the object to which the first expression points, and is an lvalue. 80) Unlike uses of the. operator, there are no situations where a pointer can refer to an object that is not an lvalue (although many implementations internal processing of the offsetof macro casts and dereferences lvalue NULL). The issue of members having a bit-field type is discussed elsewhere. () sequential nesting * bit-field in expression 1036 If the first expression is a pointer to a qualified type, the result has the so-qualified version of the type of the designated member. Qualification is based on the pointed-to type. The effective type of the object is not considered. The qualifiers on the result type are the union of the set of type qualifiers on the two operands struct qualified result qualified effective type 1037 One special guarantee is made in order to simplify the use of unions: if a union contains several structures union special guarantee that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. At one level this guarantee is codifying existing practice. At another level it specifies a permission, given by the standard to developers, which a translator needs to take account of when performing pointer alias analysis. alias analysis This guarantee is an exception to the general rule that reading the value of a member of a union type after a value has been stored into a different member results in unspecified behavior. It only applies when two or value stored in union more structure types occur within the definition of the same union type. Being contained within the definition of a union type acts as a flag to the translator; pointers to objects having these structure types may be aliased. Two or more structure types may share a common initial sequence. But if these types do not appear together within the same union type, a translator is free to assume that pointers to objects having these two structure types are never aliases of each other. The existing C practice, which this guarantee codifies, is an alternative solution to the following problem. The structure types representing the nodes of a tree data structure (or graph) used by algorithms, sometimes have a number of members in common and a few members that differ. To simplify the processing of these data structures a single type, representing all members, is usually defined. The following example shows one method for defining this type: 1 struct REC { 2 int kind_of_node_this_is; 3 long common_2; 4 int common_3; 5 union { 6 float differ_1; 7 short differ_2[5]; 8 char *differ_3; 9 } unique; 10 }; Use of a type built in this fashion can be inflexible. It creates a dependency between developers working with different types. The type will generally be contained in a single file with any modifications needing to January 30, 2008 v 1.1

8 Structure and union members go through a change control mechanism. There is also the potential issue of wasted storage. One of the union members may use significantly more storage than any of the other members. Allocating storage based on the value of sizeof(struct REC) could be very inefficient. An alternative solution to defining a common type is the following: 1 struct REC_1 { 2 int kind_of_node_this_is; 3 long common_2; 4 int common_3; 5 float differ_1; /* Members that differ start here. */ 6 }; 7 struct REC_2 { 8 int kind_of_node_this_is; 9 long common_2; 10 int common_3; 11 short differ_2[5]; /* Members that differ start here. */ 12 }; 13 struct REC_3 { 14 int kind_of_node_this_is; 15 long common_2; 16 int common_3; /* Members that differ start here. */ 17 char *differ_3; 18 }; union REC_OVERLAY { 21 struct REC_1 rec_1; 22 struct REC_2 rec_2; 23 struct REC_3 rec_3; 24 }; In this case the different structures (REC_1, REC_2, etc.) could be defined in different source files, perhaps under the control of different developers. When storage is allocated for a particular kind of node, the type appearing as the operand of sizeof can be the specific type that is needed; there is no wasted storage caused by the requirements of other nodes. The wording... anywhere that a declaration of the complete type of the union is visible. is needed to handle the following situation: 1 #include <stdio.h> 2 3 union utag { 4 struct tag1 { 5 int m1; 6 double d2; 7 } st1; 8 struct tag2 { 9 int m1; 10 char c2; 11 } st2; 12 } un1; 13 afile.c 14 extern int WG14_N685(struct tag1 *pst1, struct tag2 *pst2); void f(void) 17 { 18 if (WG14_N685(&un1.st1, &un1.st2)) 19 printf("optimized\n"); 20 else 21 printf("unoptimized\n"); 22 } v 1.1 January 30, 2008

9 Structure and union members 1037 If the two structure declarations did not appear within the same union declaration in the following translation unit, a translator would be at liberty to perform the optimization described earlier. 1 union utag { 2 struct tag1 { 3 int m1; 4 double d2; 5 } st1; 6 struct tag2 { 7 int m1; 8 char c2; 9 } st2; 10 } un1; 11 bfile.c 12 int WG14_N685(struct tag1 *pst1, struct tag2 *pst2) 13 { 14 pst1->m1 = 2; 15 pst2->m1 = 0; /* Could be an alias for pst1->m1 */ 16 return pst1->m1; 17 } tag declared with same C90 The wording: anywhere that a declaration of the complete type of the union is visible. was added in C99 to handle a situation that was raised too late in the process to be published in a Technical Report. Another wording change relating to accessing members of union objects is discussed elsewhere. C++ Like C90, the C++ Standard does not include the words... anywhere that a declaration of the complete type of the union is visible. Other Languages This kind of guarantee is unique to C (and C++). However, other languages support functionality that addresses the same problem. Two languages commonly associated with the software development of applications requiring high-integrity, Pascal and Ada, both support a form of the union type within a structure type supported by C. Common Implementations All implementations known to your author assign the same offset to members of different structure types, provided the types of all the members before them in the definition are compatible. Coding Guidelines The idea of overlaying members from different types seems to run counter to traditional thinking on how to design portable, maintainable programs. The C Standard requires an implementation to honor this guarantee so its usage is portable. The most common use of common initial sequences is in dynamic data structures. These involve pointers and pointers to different structure types which are sometimes cast to each others types. There can be several reasons for this usage, including: Sloppy programming, minimal change maintenance, or a temporary fix that becomes permanent; for instance, some form of tree data structure whose leafs have some structure type. An enhancement requires a new list of members representing completely different information, and rather than add these members to the existing structure, it is decided to create a new structure type (perhaps to save space). Changing the type of the member that points at the leafs, to have a union type (its members 1044 EXAMPLE member selection value stored in union January 30, 2008 v 1.1

10 Structure and union members having the types of the two structures), would require changing accesses to that member to include the name of the appropriate union member. Existing code could remain unchanged if the existing member types remained the same. Any references to the new structure type is obtained by casting the original pointer type. Support for subtyping, inheritance, or class hierarchies constructs not explicitly provided in the C language. The following discussion is based on the research of Stiff et al., [5, 6] and others. [1] In: 1 typedef struct { 2 int x, 3 y; 4 } Point; 5 6 void update_position(point *); 7 8 typedef enum { RED, BLUE, GREEN } Color; 9 10 typedef struct { 11 int x, 12 y; 13 Color c; 14 } Color_Point; 15 typedef struct { 16 Point where; 17 Color c; 18 } CW_Point; 19 typedef struct { 20 char base[sizeof(point)]; 21 Color c; 22 } CA_Point; void change_color(color_point *); void f(void) 27 { 28 Point a_point; 29 Point *some_point; 30 Color_Point a_color_point; 31 CW_Point a_c_point; 32 /*... */ 33 update_position((point *)&a_color_point); 34 update_position(&a_c_point.where); 35 /*... */ 36 some_point = (Point *)&a_color_point; /* An upcast. */ 37 /*... */ 38 change_color((color_point *)some_point); /* A downcast. */ 39 } common initial sequence 1038 structure type sequentially allocated objects the types Color_Point, CW_Point and CA_Point can be thought of as subtypes of Point, one having the same common initial sequence as Point (guaranteeing that the members x and y will have the same offsets) and the other making use of its definition. Both forms of definition are found in source code. The issue is not about how the contents of structures are defined, but about how their usage may rely on layout of their members in storage. For instance, developers who depend on member layout to reinterpret an object s contents. In the above example a call to update_position requires an argument of type Point *. The design of the data structures for this program makes use of the fact that all members called x and y have the same relative offsets within their respective objects. v 1.1 January 30, 2008

11 Structure and union members 1038 Commonly seen object-oriented practice is to allow objects of a derived class to be treated as if they were objects of a base class. Sometimes called an upcast (because a subtype, or class, is converted to a type or class). A conversion in the other direction, known as a downcast, is seen less often. Discussing how members in one structure might occupy the same relative (to the start of the structure) storage locations as members in another structure would normally bring howls of protest about unsafe practices. Rephrasing this discussion in terms of the object-oriented concepts of class hierarchies and inheritance lends respectability to the idea. The difference between this usage in C and C++ (or Java) is that there is no implicit language support for it in the former case; the details have to be looked after by the developer. It is this dependency on the developer getting the layout correct that is the weakest link. Duplicating sequences of members within different structures, as in the declaration of Color_Point, violates the single location principle, but has the advantage of removing the need for an additional dot selection in the member reference. Using a single declared type within different structures, as in CW_Point, is part of the fabric of normal software design and development, but has the disadvantage of requiring an additional member name to appear in an access. Stiff et al. base the definition of the term physical type on the layout of the members in storage. The form of the declarations of the members within the structure is not part of its physical type. Upcasting does leave open the possibility of accessing storage that does not exist; for instance, if a pointer to an object of type Point is converted to a pointer to an object of type Color_Point, and the member c is subsequently accessed through this pointer. Usage Measurements by Stiff et al. [5] of 1.36 MLOC (the SPEC95 benchmarks, gcc, binutils, production code from a Lucent Technologies product and a few other programs) showed a total of 23,947 casts involving 2,020 unique types. For the void * struct * conversion, they found 2,753 upcasts (610 unique types), 2,788 downcasts (606 unique types), and 538 cases (60 unique types) where there was no matching between the associated up/down casts. For the struct * struct * conversions, they found 688 upcasts (78 unique types), 514 downcasts (66 unique types), and 515 cases (67 unique types) where there was no relationship associated with the types Two structures share a common initial sequence if corresponding members have compatible types (and, for common initial sequence bit-fields, the same widths) for a sequence of one or more initial members. This defines the term common initial sequence. The rationale given for the same representation and alignment requirements of signed/unsigned types given in footnote 31 does not apply to a common initial sequence. Neither is a special case called out, like footnote 31 that for arguments. Also the rationale given in footnote 39 for pointer to void does apply to a common initial argument sequence. There are additional type compatibility rules called out for pointer to void and other pointer types for some operators, but there are no rules called out for common initial sequences. in call incompatible with function definition footnote 39 The requirement that successive members of the same structure have increasing addresses prevents an member address increasing implementation from reordering members, in storage, to be different from how they appear in the source (unless it can deduce that such a reordering will not affect the behavior of the program). The common initial sequence requirement thus reduces to requiring the same amount of padding between members. C++ structure unnamed padding If two types T1 and T2 are the same type, then T1 and T2 are layout-compatible types. 3.9p11 January 30, 2008 v p16

12 Structure and union members Two POD-structs share a common initial sequence if corresponding members have layout-compatible types (and, for bit-fields, the same widths) for a sequence of one or more initial members. implementation single pass POD is an acronym for Plain Old Data type. C++ requires that types be the same, while C requires type compatibility. If one member has an enumerated type and its corresponding member has the compatible integer type, C can treat these members as being part of a common initial sequence. C++ will not treat these members as being part of a common initial sequence. Common Implementations In choosing the offset from the start of the structure of each structure member, all implementations known to your author only consider the type of that member. Members that appear later in the structure type do not affect the relative offset of members that appear before them. Translators that operate in a single pass have to assume that the initial members of all structure types might be part of a common initial sequence. In the following example the body of the function f is encountered before the translator finds out that objects it contains have access types that are part of a common initial sequence. 1 struct t_1 { 2 int mem_1; 3 double mem_2; 4 char mem_3; 5 } g_1; 6 struct t_2 { 7 int mem_4; 8 double mem_5; 9 long mem_6; 10 } g_2; void f (void) 13 { /* Code accessing g_1 and g_2 */ } union { 16 struct t_1 mem_7; 17 struct t_2 mem_8; 18 } u; /*... */ Coding Guidelines A common initial sequence presents a number of maintenance problems, which are all derived from the same requirement the need to keep consistency between textually different parts of source code (and no translator diagnostics if there is no consistency). The sequence of preprocessing tokens forming a common initial sequence could be duplicated in each structure definition, or the common initial sequence could be held in its own source file and #included in all the structure type definitions that define the members it contains. Since the cost/benefit of the different approaches is unknown, and there is no established existing practice that addresses the software engineering issues associated with reliably maintaining a consistent common initial sequence, no recommendations are made here. Example 1 typedef short int BUCKET; 2 3 struct R_1 { 4 short int mem_1; 5 int mem_2 : 1+1; 6 unsigned char mem_3; 7 }; v 1.1 January 30, 2008

13 Structure and union members struct R_2 { 9 short mem_1; 10 int mem_2 : 2; 11 short mem_3; /* Not a common initial sequence member. */ 12 }; 13 struct R_3 { 14 short int member_1; 15 int mem_2 : 3-1; 16 long mem_3; 17 }; 18 struct R_4 { 19 BUCKET mem_1; 20 int mem_2 : 1+1; 21 float mem_3; 22 }; 23 union node_rec { 24 struct R_1 n_1; 25 struct R_2 n_2; 26 struct R_3 n_3; 27 struct R_4 n_4; 28 }; 1039 EXAMPLE 1 If f is a function returning a structure or union, and x is a member of that structure or union, f().x is a valid postfix expression but is not an lvalue. It is not an lvalue because it occurs in a context where an lvalue is converted to a value. lvalue converted to value 1040 EXAMPLE 2 In: EXAMPLE qualifiers struct s { int i; const int ci; }; struct s s; const struct s cs; volatile struct s vs; the various members have the types: s.i s.ci cs.i cs.ci vs.i vs.ci int const int const int const int volatile int volatile const int Other examples are given elsewhere. derived type qualification qualified array type ) If &E is a valid pointer expression (where & is the address-of operator, which generates a pointer to its footnote 80 operand), the expression (&E)->MOS is the same as E.MOS. Similarly, if P is a valid pointer expression, the expression (*P).MOS is the same as P->MOS. The term address-of is commonly used by developers to denote the & operator. C++ The C++ Standard does not make this observation. January 30, 2008 v 1.1

14 Structure and union members footnote DR283 union type overlapping members type punning union object representation object initial value indeterminate value stored in union object representation value representation trap representation reading is undefined behavior EXAMPLE member selection DR283) If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in (a process sometimes called "type punning"). The issue accessing overlapping union members and type punning is discussed elsewhere. An object representation is the sequence of bytes that is interpreted, using a type, to form a value. The member being accessed may include bytes that are not within the object last written to. These bytes may have an indeterminate or an unspecified value. This footnote was added by the response to DR #283. This might be a trap representation. The same object representation may be a value representation when interpreter using one type but a trap representation when interpreted using another type (e.g., a value of type long may be a trap representation when its object representation is reinterpreted as the type float). Accessing a trap representation causes undefined behavior. This footnote was added by the response to DR #283. EXAMPLE 3 The following is a valid fragment: union { struct { int alltypes; } n; struct { int type; int intnode; } ni; struct { int type; double doublenode; } nf; } u; u.nf.type = 1; u.nf.doublenode = 3.14; /*... */ if (u.n.alltypes == 1) if (sin(u.nf.doublenode) == 0.0) /*... */ The following is not a valid fragment (because the union type is not visible within function f): struct t1 { int m; }; struct t2 { int m; }; int f(struct t1 *p1, struct t2 *p2) { if (p1->m < 0) p2->m = -p2->m; return p1->m; } int g() { union { struct t1 s1; struct t2 s2; } u; v 1.1 January 30, 2008

15 Structure and union members 1045 } /*... */ return f(&u.s1, &u.s2); The sense of not a valid fragment in the second example is unspecified behavior (because different members of a union type are being accessed without an intervening store). Given the arguments passed to the function value stored in union f, the likely behavior is to return the absolute value of the member m. C90 In C90 the second fragment was considered to contain implementation-defined behavior. C++ The behavior of this example is as well defined in C++ as it is in C90. Common Implementations An optimizer might assume that the objects pointed at by the parameters of f are disjoint (because there is no connection between the structure types t1 and t2 at the time the function f is first encountered during translation). There is a long history of C translators being able to operate in a single pass over the source implementation single pass code and in some cases the function f might be completely translated before moving on to the function g (the example could have put g in a separate file). Given the availability of sufficient registers, an optimizer (operating in a single pass) may hold the contents of p1->m in a different register to the contents of p2->m. So, although the member m will hold a positive value after the call to f, the value returned by both functions could be negative Forward references: address and indirection operators ( ), structure and union specifiers ( ). January 30, 2008 v 1.1

16 References 1. S. Chandra and T. Reps. Physical type checking for C. In Proceedings of the ACM SIGPLAN-SIGSOFT Workshop on Program Analysis for Software Tools and Engineering, volume 24.5 of Software Engineering Notes (SEN), pages 66 75, N. Y., Sept ACM Press. 2. ISO. ISO/IEC :1990 Information technology Portable Operating System Interface (POSIX). ISO, Keil. C Compiler manual. Keil Software, Inc,??? edition, May C.-K. Luk and T. C. Mowry. Compiler-based prefetching for recursive data structures. In Proceedings of the Seventh International Conference on Architectural Support for Programming Languages and Operating Systems, pages , Oct M. Stiff, S. Chandra, T. Ball, K. Kunchithapadam, and T. Reps. Coping with type casts in C. Technical Report Technical Report BL , Bell Laboratories, M. B. Stiff. Techniques for software renovation. PhD thesis, University of Wisconsin-Madison, K. Thompson. Plan 9 C compilers. In Plan 9 Programmer s Manual. AT&T Bell Laboratories, X/Open Company Ltd. Go Solo How to implement and Go Solo with the Single UNIX Specification. Prentice Hall, Inc, v 1.1 January 30, 2008