Proposed resolution:

This wording is relative to N3376.

1. Change [library.c] p1 as indicated:

   -1- The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety and data race avoidance.

[ Lenexa 2015-05-05: Move to Resolved ]

JW: it's a bit odd that the issue title says sould not impose requirements on C libs, then the P/R does exactly that. Does make sense though, previously we imposed an implicit requirement which would not have been met. Now we say it explicitly and require it is met.

STL: I think this is Resolved, it has been fixed in the working paper [support.runtime]/6 is an example where we call out where things can race. That implies that for everything else they don't create races.

JW: I'm not sure, I think we still need the "and data race avoidance" to clarify that the features from C avoid races, even though C99 says no such thing.

STL: [library.c] says that something like sqrt is part of the C++ Standard LIbrary. [res.on.data.races] then applies to them. Would be OK with a note there, but am uncomfortable with "and data race avoidance" which sounds like it's making a very strong guarantee.

ACTION ITEM JW to editorially add note to [library.c] p1: "Unless otherwise specified, the C Standard Library functions shall meet the requirements for data race avoidance (xref [res.on.data.races])"

Move to Resolved?

10 in favor, 0 opposed, 3 abstentions

[ 2012, Portland ]

The concurrency subgroup decided to encourage the LWG to consider a change to [library.c] or thereabouts to clarify that we are requiring C++-like thread-safety for setlocale, so that races are not introduced by C locale accesses, even when the C library allows it. This would require e.g. adding "and data race avoidance" at the end of [library.c] p1:

"The C++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety and data race avoidance.",

with some further clarifications in the sections mentioned in 1526.

This seems to be consistent with existing implementations. This would technically not be constraining C implementation, but it would be further constraining C libraries used for both C and C++.

[ 2012, Kona ]

Re-opened at the request of the concurrency subgroup, who feel there is an issue that needs clarifying for the (planned) 2017 standard.

[ 2011 Bloomington ]

Alisdair: PJ, does this cause a problem in C?

PJ: Every implementation know of is thread safe.

Pete: There a couple of effects that are specified on strtol() and sprintf() which is a problem.

PJ: When C++ talks about C calls it should be "as if" calling the function.

Pete: Culprit is to string stuff. My fault.

PJ: Not your fault. You did what you were told. Distinct resolution to change wording.

Dietmar: What would we break if we change it back?

Pete: Nothing. If implemented on top of thread safe C library you are just fine.

Alisdair: Anyone want to clean up wording and put it back to what Pete gave us?

Alisdair: No volunteers. Do we want to mark as NAD? We could leave it as deferred.

Stefanus: Did original submitter care about this?

Lawrence: There is some work to make local calls thread safe. The resolution would be to call those thread safe version.

Pete: "As if called under single threaded C program"

Action Item (Alisdair): Write wording for this issue.

[ 2011-03-24 Madrid meeting ]

Deferred

Addresses GB-111

Section [res.on.data.races], Data Race Avoidance, requires the C++ Standard Library to avoid data races that might otherwise result from two threads making calls to C++ Standard Library functions on distinct objects. The C standard library is part of the C++ Standard Library and some C++ Standary library functions (parts of the Localization library, as well as Numeric Conversions in 21.5), are specified to make use of the C standard library. Therefore, the C++ standard indirectly imposes a requirement on the thread safety of the C standard library. However, since the C standard does not address the concept of thread safety conforming C implementations exist that do no provide such guarantees. This conflict needs to be reconciled.

Suggested resolution by national body comment:

remove the requirement to make use of strtol() and sprintf() since these functions depend on the global C locale and thus cannot be made thread safe.