References to "raise" should probably be to "std::raise" #285
Assignees
Comments
jensmaurer
added a commit
to jensmaurer/draft
that referenced
this issue
Nov 12, 2016
remove redundant description of same-thread signal handler execution Fixes cplusplus#285.
zygoloid
pushed a commit
that referenced
this issue
Nov 17, 2016
remove redundant description of same-thread signal handler execution Fixes #285.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In N3936 (from the future) and the C++14 DIS, we reference the function
raiseseveral times. Instead we should referencestd::raiseand 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 [..]The text was updated successfully, but these errors were encountered: