Movatterモバイル変換

[Moved to DR at the November, 2014 meeting.]

Additional note, February, 2014:

Two editorial changes have been made since CWG approved the proposedresolution:

1. The proposed change to 5.13.5 [lex.string] paragraph 15 hasnot been made. The termstring-literal refers to the syntacticconstruct appearing in the source, but the addition of the terminating nullcharacter is made to the concatenated string literal, which is(appropriately) referred to in the preceding paragraph (as in the originaltext of paragraph 15) using the English term, not the non-terminal.

2. The deletion of the requirement in 9.2.3 [dcl.fct.spec] paragraph 4that string literals in inline functions be the same madethe note following that requirement irrelevant, so the deletion has beenextended to include the note as well.

The issue has been returned to "review" status to allow possiblereconsideration of these editorial changes.

Proposed resolution (February, 2014):

1. Change 5.13.5 [lex.string] paragraph 1 as follows:

Astring literalstring-literal is a sequenceof characters...

2. Change 5.13.5 [lex.string] paragraph 2 as follows:

Astring literalstring-literal that hasanR in the prefix...

3. Change 5.13.5 [lex.string] paragraph 6 as follows:

After translation phase 6, astringliteralstring-literal that does not begin...

4. Change 5.13.5 [lex.string] paragraph 7 as follows:

Astring literalstring-literal that beginswithu8...

5. Change 5.13.5 [lex.string] paragraph 10 as follows:

Astring literalstring-literal that beginswithu, such asu"asdf", is achar16_t stringliteral. Achar16_t string literal has type “arrayofnconst char16_t”, wheren is the size ofthe string as defined below; ithas static storage durationand is initialized with the given characters. A singlec-charmay produce more than onechar16_t character in the form ofsurrogate pairs.

6. Change 5.13.5 [lex.string] paragraph 11 as follows:

Astring literalstring-literal that beginswithU, such asU"asdf", is achar32_t stringliteral. Achar32_t string literal has type “arrayofnconst char32_t”, wheren is the size ofthe string as defined below; it has static storage durationandis initialized with the given characters.

7. Change 5.13.5 [lex.string] paragraph 12 as follows:

Astring literalstring-literal that beginswithL, such asL"asdf", is a wide string literal. A widestring literal has type “array ofnconstwchar_t”, wheren is the size of the string as definedbelow; ithas static storage duration and is initialized withthe given characters.

8. Delete 5.13.5 [lex.string] paragraph 13:

Whether all string literals are distinct (that is, are stored innonoverlapping objects) is implementation-defined. The effect of attemptingto modify a string literal is undefined.

9. Change 5.13.5 [lex.string] paragraph 14 as follows:

In translation phase 6 (5.2 [lex.phases]), adjacentstringliteralsstring-literals are concatenated. Ifbothstring literalsstring-literals have thesameencoding-prefix, the resulting concatenated string literal hasthatencoding-prefix. If onestringliteralstring-literal hasnoencoding-prefix, it is treated as astringliteralstring-literal of thesameencoding-prefix as the other operand. If a UTF-8 string literaltoken is adjacent to a wide string literal token, the program isill-formed. Any other concatenations are conditionally-supported withimplementation-defined behavior. [Note: This concatenation is aninterpretation, not a conversion. Because the interpretation happens intranslation phase 6 (after each character from a literal has beentranslated into a value from the appropriate character set), astringliteralstring-literal's initial rawness has noeffect on the interpretation or well-formedness of theconcatenation. —end note] Table 8...

10. Add the following as a new paragraph at the end of5.13.5 [lex.string]:

Evaluating astring-literal results in a string literalobject with static storage duration, initialized from the given charactersas specified above. Whether all string literals are distinct (that is,are stored in nonoverlapping objects) and whether successive evaluationsof astring-literal yield the same or a different object isunspecified. [Note: The effect of attempting to modify a stringliteral is undefined. —end note]

11. Change 9.2.3 [dcl.fct.spec] paragraph 4 as follows:

...Astatic local variable in anextern inline functionalways refers to the same object.A string literal in the body ofanextern inline function is the same object in differenttranslation units. [Note: A string literal appearing in a defaultargument is not in the body of an inline function merely because theexpression is used in a function call from that inlinefunction. —end note] A type defined within the body ofanextern inline function is the same type in every translationunit.

According to 9.2.3 [dcl.fct.spec] paragraph 4,

A string literal in the body of an extern inline function isthe same object in different translation units.

The Standard does not otherwise specify when string literals arerequired to be the same object, and this requirement is not widelyimplemented. Should it be removed?