Document Number: WG14 N672/X3J11 97-035 C9X Revision Proposal ===================== Title: reorder subclauses 6.1 and 6.2 Author: Clive D.W. Feather Author Affiliation: Demon Internet Ltd Postal Address: 322 Regents Park Road, London N3 2QQ, UK E-mail Address: clive@demon.net Telephone Number: +44 181 371 1138 Fax Number: +44 181 371 1037 Date: 1997-03-03 Sponsor: BSI/WG14 Proposal Category: XX Editorial change/non-normative contribution XX Correction __ New feature __ Addition to obsolescent feature list __ Addition to Future Directions __ Other (please specify) ______________________________ Area of Standard Affected: __ Environment XX Language __ Preprocessor __ Library __ Macro/typedef/tag name __ Function __ Header __ Other (please specify) ______________________________ Prior Art: n/a Target Audience: all Related Documents (if any): none Proposal Attached: Yes Abstract: Subclauses 6.1 and 6.2 are badly organised, and the former contains a number of ambiguities and inconsistencies. This proposal is a general cleanup. Notes: This proposal was prepared with the assistance of Mark Brader, Jutta Degener, Ron Guilmette, and a person whose employment conditions require anonymity. Summary ------- Subclauses 6.1 and 6.2 are badly organised, and the former contains a number of ambiguities and inconsistencies. This proposal is a general cleanup. Conformance ----------- The author believes that no strictly-conforming program is affected by this proposal. Discussion ---------- The following changes have been made. (1) The important concepts of scope, linkage, namespaces, storage durations, and types have been separated out from a subclause of a lexical concept to a major element of their own. To minimize impact on numbering, the text on conversions (6.2) is merged with this to become the new 6.1. The remainder of 6.1, which is actually the lexical elements, becomes 6.2. Alternatively, the conversions material could remain as 6.2 and the remainder of 6.1 would become 6.3. This would require renumbering the whole of subclause 6. The changes aid the reader of the Standard, in particular by reducing the need for forward references. It does not alter the language defined. See the basic proposal and the specific changes marked (D), (F), and (G). (2) The current standard attempts to treat both operators and punctuators as syntactic elements. This means that several tokens (including the keyword "sizeof" occur twice. Instead, punctuator is made a syntactic concept, and operator a semantic one. The effect is to eliminate some minor syntactic ambiguities (various tokens have multiple derivations) and make the concepts clearer. It does not alter the language defined. See the specific changes marked (A) and (F). (3) The header name changes of TC1 have been further amended for clarity. It does not alter the language defined. See the specific change marked (B). (4) Various nugatory constraints are eliminated. Any program which violates these constraints also violates one or more syntax rules. It does not alter the language defined. See the specific changes marked (C) and (F). (5) It is made clear that '\z' is a syntax error for all escape sequences other than those listed (footnote 32 and the text that refers to it contradict the syntax). See the specific change marked (E). Detailed proposal ----------------- Restructure subclauses 6.1 and 6.2 according to the following table, and alter cross-references throughout the Standard accordingly. New number Title Old number ------------------------------------------------------------ 6.1 Concepts none 6.1.1 Scopes of identifiers 6.1.2.1 6.1.2 Linkages of identifiers 6.1.2.2 6.1.3 Name spaces of identifiers 6.1.2.3 6.1.4 Storage durations of objects 6.1.2.4 6.1.5 Types 6.1.2.5 6.1.6 Compatible type and composite type 6.1.2.6 6.1.7 Conversions 6.2 6.1.7.1 Characters and integers 6.2.1.1 6.1.7.2 Signed and unsigned integers 6.2.1.2 6.1.7.3 Real floating and integral 6.2.1.3 6.1.7.4 Real floating types 6.2.1.4 6.1.7.5 Complex types 6.2.1.5 6.1.7.6 Real and complex 6.2.1.6 6.1.7.7 Usual arithmetic conversions 6.2.1.7 6.1.7.8 Lvalues and function designators 6.2.2.1 6.1.7.9 void 6.2.2.2 6.1.7.10 Pointers 6.2.2.3 6.2 Lexical elements 6.1 6.2.1 Keywords 6.1.1 6.2.2 Identifiers 6.1.2 6.2.3 Constants 6.1.3 6.2.3.1 Floating constants 6.1.3.1 6.2.3.2 Integer constants 6.1.3.2 6.2.3.3 Enumeration constants 6.1.3.3 6.2.3.4 Character constants 6.1.3.4 6.2.4 String literals 6.1.4 6.2.5 Punctuators none 6.2.6 Header names 6.1.7 6.2.7 Preprocessing numbers 6.1.8 6.2.8 Comments 6.1.9 Delete the old subclauses 6.1.5 and 6.1.6; the new subclause 6.2.5 is given below. Insert and remove forward references as necessary. Additionally, make the following specific changes. ====== (A) In subclause 6.2 (formerly 6.1) syntax, remove the alternative "operator" from both "token" and "preprocessing-token". In the constraints, remove "an operator,". In the semantics, remove "operators," (twice). (B) In subclause 6.2 (formerly 6.1) semantic, combine the last two paragraphs into one, replacing: A header name at the start of the last paragraph, with There is one exception to this rule: a header name (C) In subclause 6.2.2 (formerly 6.1.2), delete the constraints. (D) In subclause 6.2.2 (formerly 6.1.2) paragraph 4 (the first paragraph of the semantics), replace: that will be described later: with described in subclause 6.1.1: (E) In subclause 6.2.3.4 (formerly 6.1.3.4) description, delete the sentence: If any other escape sequence is encountered, the behaviour is undefined.[32] Delete footnote 32. Add the following text at the end of footnote 31: If any other character follows a backslash, the result is not a token and a diagnostic is required. See ``future language directions'' (6.9.2). (F) Insert a new subclause 6.2.5 (replacing the old 6.1.5 and 6.1.6): Syntax punctuator: one of [ ] ( ) { } . -> ++ -- & * + - ~ ! / % << >> < > <= >= == != ^ | && || ? : ; ... = *= /= %= += -= <<= >>= &= ^= |= , # ## <: :> <% %> %: %:%: Semantics A punctuator is a symbol that has independent syntactic and semantic significance. Depending on context, it may specify an operation to be performed (which in turn may yield a value or a designator, or produce a side effect, or some combination) in which case it is known as an *operator* (other forms of operator also exist in some contexts). An *operand* is an entity on which an operator acts. In all aspects of the language, these six tokens <: :> <% %> %: %:%: behave, respectively, the same as these six tokens [ ] { } # ## except for their spelling.[34] [34] Thus [ and <: behave differently when ``stringized'' (see subclause 6.8.3.2), but can otherwise be freely interchanged. Forward references: expressions (6.3), declarations (6.5), preprocessing directives (6.8), statements (6.6). (G) In subclause 6.3.17, replace the first sentence of the example with: As indicated by the syntax, the comma operator (as described in this subclause) cannot appear in contexts where a comma is used to separate items in a list (such as arguments to functions or lists of initializers). -- Clive D.W. Feather | Associate Director | Director Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd. Fax: +44 181 371 1150 | | Written on my laptop - please reply to the Reply-To address