Issue 2414: Member function reentrancy should be implementation-defined

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

2414. Member function reentrancy should be implementation-defined

Section: 16.4.6.9 [reentrancy] Status: Open Submitter: Stephan T. Lavavej Opened: 2014-07-01 Last modified: 2021-07-31

Priority: 3

View all other issues in [reentrancy].

View all issues with Open status.

Discussion:

N3936 16.4.6.9 [reentrancy]/1 talks about "functions", but that doesn't address the scenario of calling different member functions of a single object. Member functions often have to violate and then re-establish invariants. For example, vectors often have "holes" during insertion, and element constructors/destructors/etc. shouldn't be allowed to observe the vector while it's in this invariant-violating state. The [reentrancy] Standardese should be extended to cover member functions, so that implementers can either say that member function reentrancy is universally prohibited, or selectively allowed for very specific scenarios.

(For clarity, this issue has been split off from LWG 2382.)

[2014-11-03 Urbana]

AJM confirmed with SG1 that they had no special concerns with this issue, and LWG should retain ownership.

AM: this is too overly broad as it also covers calling the exact same member function on a different object
STL: so you insert into a map, and copying the value triggers another insertion into a different map of the same type
GR: reentrancy seems to imply the single-threaded case, but needs to consider the multi-threaded case

Needs more wording.

Move to Open

[2015-07 Telecon Urbana]

Marshall to ping STL for updated wording.

[2016-05 email from STL]

I don't have any better suggestions than my original PR at the moment.

Previous resolution [SUPERSEDED]:

This wording is relative to N3936.

Change 16.4.6.9 [reentrancy] p1 as indicated:

-1- Except where explicitly specified in this standard, it is implementation-defined which functions (including different member functions called on a single object) in the Standard C++ library may be recursively reentered.

[2021-07-29 Tim suggests new wording]

The "this pointer" restriction is modeled on 11.9.5 [class.cdtor] p2. It allows us to continue to specify a member function f as calling some other member function g, since any such call would use something obtained from the first member function's this pointer.

In all other cases, this wording disallows such "recursion on object" unless both member functions are const (or are treated as such for the purposes of data race avoidance). Using "access" means that we also cover direct access to the object representation, such as the following pathological example from Arthur O'Dwyer, which is now undefined:

std::string s = "hello world";
char *first = (char*)&s;
char *last = (char*)(&s + 1);
s.append(first, last);

Proposed resolution:

This wording is relative to N4892.

Add the following paragraph to 16.4.6.9 [reentrancy]:

-?- During the execution of a standard library non-static member function F on an object, if that object is accessed through a glvalue that is not obtained, directly or indirectly, from the this pointer of F, in a manner that can conflict (6.9.2.2 [intro.races]) with any access that F is permitted to perform (16.4.6.10 [res.on.data.races]), the behavior is undefined unless otherwise specified.