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

Additional note, February, 2014:

Two editorial changes have been made since CWG approved the proposed resolution:

1. The proposed change to 5.13.5 [lex.string] paragraph 15 has not been made. The term string-literal refers to the syntactic construct appearing in the source, but the addition of the terminating null character is made to the concatenated string literal, which is (appropriately) referred to in the preceding paragraph (as in the original text 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 4 that string literals in inline functions be the same made the note following that requirement irrelevant, so the deletion has been extended to include the note as well.

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

Proposed resolution (February, 2014):

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

A string literal string-literal is a sequence of characters...

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

A string literal string-literal that has an R in the prefix...

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

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

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

A string literal string-literal that begins with u8...

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

A string literal string-literal that begins with u, such as u"asdf", is a char16_t string literal. A char16_t string literal has type “array of n const char16_t”, where n is the size of the string as defined below; it has static storage duration and is initialized with the given characters. A single c-char may produce more than one char16_t character in the form of surrogate pairs.

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

A string literal string-literal that begins with U, such as U"asdf", is a char32_t string literal. A char32_t string literal has type “array of n const char32_t”, where n is the size of the string as defined below; it has static storage duration and is initialized with the given characters.

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

A string literal string-literal that begins with L, such as L"asdf", is a wide string literal. A wide string literal has type “array of n const wchar_t”, where n is the size of the string as defined below; it has static storage duration and is initialized with the given characters.

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

Whether all string literals are distinct (that is, are stored in nonoverlapping objects) is implementation-defined. The effect of attempting to 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]), adjacent string literals string-literals are concatenated. If both string literals string-literals have the same encoding-prefix, the resulting concatenated string literal has that encoding-prefix. If one string literal string-literal has no encoding-prefix, it is treated as a string literal string-literal of the same encoding-prefix as the other operand. If a UTF-8 string literal token is adjacent to a wide string literal token, the program is ill-formed. Any other concatenations are conditionally-supported with implementation-defined behavior. [Note: This concatenation is an interpretation, not a conversion. Because the interpretation happens in translation phase 6 (after each character from a literal has been translated into a value from the appropriate character set), a string literal string-literal's initial rawness has no effect on the interpretation or well-formedness of the concatenation. —end note] Table 8...

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

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

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

...A static local variable in an extern inline function always refers to the same object. A string literal in the body of an extern inline function is the same object in different translation units. [Note: A string literal appearing in a default argument is not in the body of an inline function merely because the expression is used in a function call from that inline function. —end note] A type defined within the body of an extern inline function is the same type in every translation unit.

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

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

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