From 535cc5a96c0b506e12ae971c908a482fba240f91 Mon Sep 17 00:00:00 2001 From: Jonathan Wakely Date: Thu, 7 Nov 2024 13:04:47 +0000 Subject: [PATCH] Remove trailing whitespace from 2088 --- xml/issue2088.xml | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/xml/issue2088.xml b/xml/issue2088.xml index 16f7a7790e..7b47dd4d0d 100644 --- a/xml/issue2088.xml +++ b/xml/issue2088.xml @@ -1,5 +1,5 @@ - ] > @@ -22,11 +22,11 @@ paragraph 1 reads

Remarks: Called by the implementation when exception handling must -be abandoned for any of several reasons (15.5.1), in effect immediately after -evaluating the throw-expression (18.8.3.1). May also be called directly by the +be abandoned for any of several reasons (15.5.1), in effect immediately after +evaluating the throw-expression (18.8.3.1). May also be called directly by the program.

-

It is not clear what is "in effect". It was clear in previous drafts where paragraphs +

It is not clear what is "in effect". It was clear in previous drafts where paragraphs 1 and 2 read:

@@ -61,18 +61,18 @@ that was in effect immediately after evaluating the throw-expression". triggered by the implementation - no throw-expression involved.

  • - In case a destructor throws during stack unwinding we have two throw-expressions + In case a destructor throws during stack unwinding we have two throw-expressions involved.

    • Which one is referred to?

    -In case std::nested_exception::rethrow_nested is called for an object that has -captured no exception, there is no throw-expression involved directly (and may no throw +In case std::nested_exception::rethrow_nested is called for an object that has +captured no exception, there is no throw-expression involved directly (and may no throw be involved even indirectly).

    -Next, , paragraph 2 says +Next, , paragraph 2 says

    Required behavior: A terminate_handler shall terminate execution @@ -84,33 +84,33 @@ exception (because word "return" implies a normal return).

    One could argue that words "terminate execution of the program" are sufficient, but then why "without returning to the caller" would be mentioned. In -case such handler throws, noexcept specification in function std::terminate -is violated, and std::terminate would be called recursively - should -std::abort not be called in case of recursive std::terminate -call? On the other hand some controlled recursion could be useful, like in the +case such handler throws, noexcept specification in function std::terminate +is violated, and std::terminate would be called recursively - should +std::abort not be called in case of recursive std::terminate +call? On the other hand some controlled recursion could be useful, like in the following technique.

    -The here mentioned wording changes by N3189 in regard to p1 -were done for a better separation of effects (Effects element) and additional normative +The here mentioned wording changes by N3189 in regard to p1 +were done for a better separation of effects (Effects element) and additional normative wording explanations (Remarks element), there was no meaning change intended. Further, -there was already a defect existing in the previous wording, which was not updated when -further situations where defined, when std::terminate where supposed to be -called by the implementation. +there was already a defect existing in the previous wording, which was not updated when +further situations where defined, when std::terminate where supposed to be +called by the implementation.

    The part

    "in effect immediately after evaluating the throw-expression"

    -should be removed and the quoted reference to -need to be part of the effects element where it refers to the current terminate_handler +should be removed and the quoted reference to +need to be part of the effects element where it refers to the current terminate_handler function, so should be moved just after

    "Effects: Calls the current terminate_handler function."

    -It seems ok to allow a termination handler to exit via an exception, but the +It seems ok to allow a termination handler to exit via an exception, but the suggested idiom should better be replaced by a more simpler one based on evaluating the current exception pointer in the terminate handler, e.g.