Skip to content

References to "raise" should probably be to "std::raise" #285

@sdutoit

Description

@sdutoit

In N3936 (from the future) and the C++14 DIS, we reference the function raise several times. Instead we should reference std::raise and point to the section that (very minimally) declares it.

Daniel Krügler writes:

As consequence of applying

http://wiki.edg.com/twiki/pub/Wg21issaquah/FormalMotions/N3910.html

the P/R several times refers to a function "raise" without context. It
is certainly clear for us, what function is meant, but given a
previous clean-up in regard to referring to Standard Library
components from the core language I would tentatively suggest to add
the std:: qualifier to all now introduced references of "raise" and to
quote at least for the very first reference the corresponding
sub-clause in the standard-library that refers to it
([support.runtime]).

In the same line of changes it happened that the previous usages of
std::sig_atomic_t had been replaced by unqualified sig_atomic_t and I
suggest to restore the std qualifications.

The full list of suggested changes is listed here:

a) [intro.execution] p6:

If a signal handler is executed as a result of a call to the std::raise function ([support.runtime]), then the execution of the handler is sequenced after the invocation of the std::raise function and before its return.

b) [intro.multithread] p2:

A signal handler that is executed as a result of a call to the std::raise function belongs to the same thread of execution as the call to the std::raise function.

c) [intro.multithread] p24:

Two accesses to the same object of type volatile std::sig_atomic_t do not result in a data race [..] and the evaluations of such volatile std::sig_atomic_t objects take values [..]

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions