This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of WP status.

2994. Needless UB for basic_string and basic_string_view

Section: 27.2 [char.traits], 27.4.3.2 [string.require], 27.3.3 [string.view.template] Status: WP Submitter: Gennaro Prota Opened: 2017-07-03 Last modified: 2023-11-22

Priority: 3

View all other issues in [char.traits].

View all issues with WP status.

Discussion:

basic_string and basic_string_view involve undefined behavior in a few cases where it's simple for the implementation to add a static_assert and make the program ill-formed.

With regards to basic_string, 27.2 [char.traits]/3 states:

Traits::char_type shall be the same as CharT.

Here, the implementation can add a static_assert using the is_same type trait. Similar issues exist in 27.4.3.2 [string.require] and, for basic_string_view, in 27.3.3 [string.view.template]/1.

[2017-07 Toronto Tuesday PM issue prioritization]

Priority 3; need to check general container requirements

Partially by the adoption of P1148 in San Diego.

Tim opines: "the remainder deals with allocator value type mismatch, which I think is NAD."

Previous resolution [SUPERSEDED]:

This wording is relative to N4659.

  1. Edit 27.2 [char.traits] as indicated:

    -3- To specialize those templates to generate a string or iostream class to handle a particular character container type CharT, that and its related character traits class Traits are passed as a pair of parameters to the string or iostream template as parameters charT and traits. If Traits::char_type shall be the same is not the same type as CharT, the program is ill-formed.

  2. Edit 27.4.3.2 [string.require] as indicated:

    -3- In every specialization basic_string<charT, traits, Allocator>, if the type allocator_traits<Allocator>::value_type shall name the same type is not the same type as charT, the program is ill-formed. Every object of type basic_string<charT, traits, Allocator> shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed. The Allocator object used shall be obtained as described in 23.2.2 [container.requirements.general]. In every specialization basic_string<charT, traits, Allocator>, the type traits shall satisfy the character traits requirements (27.2 [char.traits]). If, and the type traits::char_type shall name the same type is not the same type as charT, the program is ill-formed.

  3. Edit 27.3.3 [string.view.template] as indicated:

    -1- In every specialization basic_string_view<charT, traits>, the type traits shall satisfy the character traits requirements (27.2 [char.traits]). If, and the type traits::char_type shall name the same type is not the same type as charT, the program is ill-formed.

[2023-05-15; Jonathan Wakely provides improved wording]

As noted above, most of this issue was resolved by P1148R0. The remainder is the change to make it ill-formed if the allocator has the wrong value_type, but since P1463R1 that is already part of the Allocator-aware container requirements, which apply to basic_string.

[2023-06-01; Reflector poll]

Set status to Tentatively Ready after eight votes in favour during reflector poll.

There was a request to editorially move the added text in Note 1 into Note 2 after this is approved.

[2023-06-17 Approved at June 2023 meeting in Varna. Status changed: Voting → WP.]

Proposed resolution:

This wording is relative to N4950.

  1. Edit 27.4.3.2 [string.require] as indicated:

    -3- In every specialization basic_string<charT, traits, Allocator>, the type allocator_traits<Allocator>::value_type shall name the same type as charT. Every object of type basic_string<charT, traits, Allocator> shall use an object of type Allocator to allocate and free storage for the contained charT objects as needed. The In every specialization basic_string<charT, traits, Allocator>, the type traits shall satisfy the character traits requirements (27.2 [char.traits]).

    [Note 1: Every specialization basic_string<charT, traits, Allocator> is an allocator-aware container, but does not use the allocator’s construct and destroy member functions (23.2.2 [container.requirements.general]). The program is ill-formed if Allocator::value_type is not the same type as charT. — end note]

    [Note 2: The program is ill-formed if traits::char_type is not the same type as charT. — end note]