Implementation-defined names cannot be reserved words AI-00009/10 1 93-06-24 BI WA | !standard 02.08 (09) 93-06-24 AI-00009/10 !standard 02.09 (01) !standard 04.01.04 (04) !class binding interpretation 87-05-26 | !status approved by WG9 93-06-18 !status ARG-approved 93-01-18 (reviewed) !status panel-approved (10-0-3) 87-06-30 (by mail) (pending editorial review) !status committee-approved (7-0-0) 87-05-26 (pending editorial review) !status panel/committee-approved (6-0-0) 86-11-14 (pending editorial review) !status work-item 83-10-10 !references AI-00010, AI-00509, 83-00022, 83-01016 !topic Implementation-defined names cannot be reserved words !SUMMARY 93-01-25 An implementation-defined name must not be a reserved word. In particular: - The identifier of an implementation-defined pragma must not be a reserved word. - An argument association of an implementation-defined pragma must not use a reserved word as an argument identifier. - The identifier of an implementation-defined attribute must not be a reserved word. - An implementation-defined record component name must not be a reserved word. If a reserved word appears as the identifier of a pragma or as the identifier of a pragma argument, an implementation must either reject the pragma or treat the pragma as having no effect. (Of course, since the language does not restrict text that is to be processed by some tool, a preprocessor directive may have name that is a reserved word.) !QUESTION 87-09-22 Are the following prohibited by any language rule? pragma NULL; -- (1) legal? (no) pragma PLACE (A, IN => B); -- (2) legal? (no) pragma OPTIMIZE (FOR => TIME); -- (3) legal? (no) (1) May an implementation-defined pragma identifier be a reserved word? Is an implementation required to allow (and ignore) pragmas whose identifiers are reserved words? (2) May reserved words be used as pragma argument identifiers? (3) Can an implementation-defined attribute or record component name be a reserved word? Implementation-defined names cannot be reserved words AI-00009/10 2 93-06-24 BI WA !RECOMMENDATION 89-09-25 If a reserved word is used as the identifier of a pragma or as the identifier of a pragma argument, an implementation must either reject the pragma or treat the pragma as having no effect. !DISCUSSION 93-01-25 The syntax for pragmas is given in 2.8(2): pragma ::= pragma identifier [(argument_association {, argument_association})]; argument_association ::= [ARGUMENT_identifier =>] name | [ARGUMENT_identifier =>] expression 2.9(1) states: [reserved words] are reserved for special significance in the language That is, the Standard has completely specified the use of reserved words. Hence, a reserved word is not allowed as an implementation-defined pragma identifier or as an argument identifier in an argument association of an implementation-defined pragma. Similarly, a reserved word is not allowed as an implementation-defined attribute designator or as an implementation- defined record component name. (Although the language-defined attribute designators, DELTA, DIGITS, and RANGE, are reserved words, this does not imply that implementation-defined attributes can also be reserved words. 2.9(1) allows reserved words to be used in language-defined ways, including use as language-defined attribute designators, but such use does not imply 2.9(1) can be ignored for implementation-defined attributes.) The use of a reserved word as an implementation-defined attribute designator or as a record component name is clearly illegal because such a use is forbidden by 2.9(1). (Since ramifications of rules in the Standard are not specified as recommendations in binding interpretations, this consequence of 2.9(1) does not appear in the recommendation of this Commentary.) It is less clear whether an implementation must reject a program that (accidentally) uses a reserved word as a pragma identifier or as a pragma argument. 2.8(9) says: A pragma that is not language-defined has no effect if its identifier is not recognized by the (current) implementation. Furthermore, a pragma (whether language-defined or implementation-defined) has no effect if its placement or its arguments do not correspond to what is allowed for the pragma. This wording suggests that if a programmer uses a reserved word as a pragma Implementation-defined names cannot be reserved words AI-00009/10 3 93-06-24 BI WA identifier or as a pragma argument identifier, the pragma should have no effect; in particular, the program containing the pragma should not be considered illegal and rejected. However, since no language-defined pragma uses a reserved word as a pragma identifier or as a pragma argument identifier, and since no implementation-defined pragma is allowed to use reserved words in these ways, there is no valid pragma that allows such uses of reserved words. The intent behind 2.8(9) was to ensure that an unrecognized pragma does not make a program illegal. Since no valid pragmas can use a reserved word as a pragma identifier or as a pragma argument identifier, it is consistent with the intent of 2.8(9) to reject compilation units containing such uses. On the other hand, when encountering a reserved word in such a position, an implementation might simply ignore the pragma by scanning to the next free-standing semicolon. Such action is also consistent with 2.8(9), since such "pragmas" have no effect. Hence, the recommendation says an implementation may either reject such constructs or ignore them. Some implementations use a pragma form for preprocessor directives, e.g., pragma IF (...); pragma INCLUDE (...); Since the language places no restrictions or requirements on preprocessors, such usage is allowed. The main effect of this commentary is to ensure that if a program using such a "pragma" is compiled without being preprocessed, an implementation can either reject the program or ignore the pragma (perhaps giving a helpful warning message).