This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115d. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-10-26
[Moved to DR at the November, 2014 meeting.]
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?
Proposed resolution (February, 2014):
Change 5.13.5 [lex.string] paragraph 1 as follows:
Astring literalstring-literal is a sequence of characters...
Change 5.13.5 [lex.string] paragraph 2 as follows:
Astring literalstring-literal that has an R in the prefix...
Change 5.13.5 [lex.string] paragraph 6 as follows:
After translation phase 6, astring literalstring-literal that does not begin...
Change 5.13.5 [lex.string] paragraph 7 as follows:
Astring literalstring-literal that begins with u8...
Change 5.13.5 [lex.string] paragraph 10 as follows:
Astring literalstring-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; ithas static storage duration andis initialized with the given characters. A single c-char may produce more than one char16_t character in the form of surrogate pairs.
Change 5.13.5 [lex.string] paragraph 11 as follows:
Astring literalstring-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; ithas static storage duration andis initialized with the given characters.
Change 5.13.5 [lex.string] paragraph 12 as follows:
Astring literalstring-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; ithas static storage duration andis initialized with the given characters.
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.
Change 5.13.5 [lex.string] paragraph 14 as follows:
In translation phase 6 (5.2 [lex.phases]), adjacentstring literalsstring-literals are concatenated. If bothstring literalsstring-literals have the same encoding-prefix, the resulting concatenated string literal has that encoding-prefix. If onestring literalstring-literal has no encoding-prefix, it is treated as astring literalstring-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), astring literalstring-literal's initial rawness has no effect on the interpretation or well-formedness of the concatenation. —end note] Table 8...
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]
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.
Additional note, February, 2014:
Two editorial changes have been made since CWG approved the proposed resolution:
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.