This is the mail archive of the
mailing list for the GCC project.
Re: Behaviour of __forced_unwind with noexcept
- From: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- To: Ron <ron at bitbabbler dot org>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- Date: Mon, 14 Aug 2017 18:22:39 +0100
- Subject: Re: Behaviour of __forced_unwind with noexcept
- Authentication-results: sourceware.org; auth=none
- References: <20170813182002.GJ12030@hex.shelbyville.oz>
On 13 August 2017 at 19:20, Ron wrote:
> I'm looking for some clarification of how the __forced_unwind thread
> cancellation exceptions intersect with noexcept. I've long been a
> big fan of the __forced_unwind idiom, but now that C++14 is the default
> since GCC 6.1, and many methods including destructors are implicitly
> noexcept, using it safely appears to have become a lot more tricky.
> The closest I've found so far to an "authoritative" statement of the
> expected behaviour is the comments from Jonathan Wakely here:
> In particular: "It interacts with noexcept as you'd expect:
> std::terminate() is called if a __forced_unwind escapes a noexcept
> function, so noexcept functions are really noexcept, they won't
> unexpectedly throw some 'special' type"
> Which does seem logical, but unless I'm missing something this makes
> it unsafe to perform any operation in a destructor which might cross
> a cancellation point, unless that destructor is noexcept(false).
Unfortunately I still think that's true.
This was also raised in https://gcc.gnu.org/ml/gcc-help/2015-08/msg00040.html
> And since that could be something as simple as logging to stdio and
> almost impossible to definitely rule out in a future proof way if the
> destructor does anything non-trivial (like calling functions in a
> system or other 3rd party library) ... and since the race of catching
> a cancellation request in such a destructor could be a relatively rare
> one to lose in a lot of code ... there could be a lot of extant code
> with new latent 'crasher' bugs when built with GCC 6.1 or later.
> And/or a lot of people are going to have to go through a lot of code
> and mark up a lot of methods with noexcept(false).
> So I'm half-hoping that I am actually missing something here which
> mitigates that - but if not, is this something we need to give a
> bit more thought to?
> (Please keep me cc'd, I'm not currently on this list)