Public Comment Number PC-UK0013 ISO/IEC CD 9899 (SC22N2620) Public Comment =========================================== Date: 1997-12-29 Author: Clive D.W. Feather Author Affiliation: Self Postal Address: Demon Internet Limited 322 Regents Park Road London N3 2QQ United Kingdom E-mail Address: Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Number of individual comments: 1 Comment 1. Category: Normative change to existing feature retaining the original intent Committee Draft subsection: 6.1.2.5, 6.5.2.1 Title: Cleanup of flexible array structure members. Detailed description: The concept of flexible array structure members, otherwise known as the "struct hack", has a number of minor problems that need fixing. Furthermore, there are some nasty implications when such a structure is used as a component of an aggregate type, this is forbidden. 6.1.2.5p17, bullet point 2, should read: A /structure type/ describes a sequentially allocated nonempty set of member objects (and, in certain circumstances, an incomplete array), each of which has an optionally specified name and possibly distinct type. 6.5.2.1p2, first sentence, should read: ... except that the last member of a structure with more than one named member may have incomplete array type; such a structure (and any union containing, possibly recursively, a member whose type is such a structure) shall not be the type of a member of a structure or of the element of an array. 6.5.2.1p15 should be replaced by: As a special case, the last member of a structure with more than one named member may have an incomplete array type. This is called a /flexible array member/, and the size of the structure shall be equal to the offset of the last member of an otherwise identical structure that replaces the flexible array member with an array of unspecified length [*]. When an lvalue whose type is a structure with a flexible array member is used to access an object, it behaves as if that member were replaced with the longest array, with the same element type, that would not make the structure larger than the object being accessed; the offset of the array shall remain that of the flexible array member, even if this would differ from that of the replacement array. If this array would have no elements, then it behaves as if it had one element, but the behavior is undefined if any attempt is made to access that element or to generate a pointer one past that element. [*] The length is unspecified to allow for the fact that some implementations may give array members different alignments according to their length. Change the start of paragraph 16 to: Assuming that all arrays have the same alignment within structures, then after the declarations: struct s { int n; double d[]; }; struct ss { int n; double d[42]; }; the three expressions: In paragraph 17, change: /s1/ and /s2/ behave as if they had been declared as: to: the objects pointed to by /s1/ and /s2/ behave as if the latter two identifiers had been declared as: