6.4 Lexical elements

• 6.4.1 Keywords
• 6.4.2 Identifiers
  • 6.4.2.1 General
  • 6.4.2.2 Predefined identifiers
• 6.4.3 Universal character names
• 6.4.4 Constants
  • 6.4.4.1 Integer constants
  • 6.4.4.2 Floating constants
  • 6.4.4.3 Enumeration constants
  • 6.4.4.4 Character constants
• 6.4.5 String literals
• 6.4.6 Punctuators
• 6.4.7 Header names
• 6.4.8 Preprocessing numbers
• 6.4.9 Comments

Syntax

1

token:

keyword

identifier

constant

string-literal

punctuator

preprocessing-token:

header-name

identifier

pp-number

character-constant

string-literal

punctuator

each non-white-space character that cannot be one of the above

Constraints

2

Each preprocessing token that is converted to a token shall have the lexical form of a keyword, an identifier, a constant, a string literal, or a punctuator.

Semantics

3

A token is the minimal lexical element of the language in translation phases 7 and 8. The categories of tokens are: keywords, identifiers, constants, string literals, and punctuators. A preprocessing token is the minimal lexical element of the language in translation phases 3 through 6. The categories of preprocessing tokens are: header names, identifiers, preprocessing numbers, character constants, string literals, punctuators, and single non-white-space characters that do not lexically match the other preprocessing token categories.[1] If a ‘ or a ” character matches the last category, the behavior is undefined. Preprocessing tokens can be separated by white space; this consists of comments (described later), or white-space characters (space, horizontal tab, new-line, vertical tab, and form-feed), or both. As described in 6.10, in certain circumstances during translation phase 4, white space (or the absence thereof) serves as more than preprocessing token separation. White space may appear within a preprocessing token only as part of a header name or between the quotation characters in a character constant or string literal.

4

If the input stream has been parsed into preprocessing tokens up to a given character, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token. There is one exception to this rule: header name preprocessing tokens are recognized only within #include preprocessing directives and in implementation-defined locations within #pragma directives. In such contexts, a sequence of characters that could be either a header name or a string literal is recognized as the former.

5

EXAMPLE 1 The program fragment 1Ex is parsed as a preprocessing number token (one that is not a valid floating or integer constant token), even though a parse as the pair of preprocessing tokens 1 and Ex might produce a valid expression (for example, if Ex were a macro defined as +1). Similarly, the program fragment 1E1 is parsed as a preprocessing number (one that is a valid floating constant token), whether or not E is a macro name.

6

EXAMPLE 2 The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.

Forward References

6.4.4.4 Character constants 6.4.9 Comments 6.5 Expressions 6.4.4.2 Floating constants 6.4.7 Header names 6.10.3 Macro replacement

6.5.2.4 Postfix increment and decrement operators 6.5.3.1 Prefix increment and decrement operators 6.10 Preprocessing directives 6.4.8 Preprocessing numbers 6.4.5 String literals

Footnotes

[1]

An additional category, placemarkers, is used internally in translation phase 4 (see 6.10.3.3); it cannot occur in source files.