Repository navigation
[csetjmp.syn] CWG2361, LWG3652: Imprecise description of UB #1778
Description
Activity
Since "stack unwinding" is only defined in the context of exceptions [except.ctor], I don't understand what exactly the improvement is with your proposal.
I do agree that the wording is sub-optimal, but I'm not sure we can find something better that is a small enough fix to be considered editorial.
The original wording is unclear beacuse it does not exactly explain which
tryblock after replacement would be catched. And as thattryblock varies it might differ whether non-trival destructors of an automatic storage objects would be invoked or not. So what about explaining thetryblock? Not sure if it is an editoral fix though.The meaning seems fairly obvious to me.
If non-trivial destructors would be invoked by transferring control from point A to point B by throwing an exception at A and catching it at B, then it's undefined to transfer control from A to B by calling
setjmpat B andlongjmpat A.@jwakely Then why don't we put your explanation
If non-trivial destructors would be invoked by transferring control from point A to point B by throwing an exception at A and catching it at B, then it's undefined to transfer control from A to B by calling
setjmpat B andlongjmpat A.in place of
A
setjmp/longjmpcall pair has undefined behavior if replacing thesetjmpandlongjmpbycatch
andthrowwould invoke any non-trivial destructors for any automatic objects.in the standard?
I still find that to have a fundamental problem: we can't throw an exception at the
longjmpand catch it at thesetjmp, because execution in the function containing thesetjmphas by definition already got past thesetjmp. Whatever rule we use needs to take into account a third point C, which is the point within the function evaluation containing thesetjmpcall at whichlongjmpis directly or indirectly invoked. And we want to consider if any local variables would be destroyed by unwinding from A to C, and also something about the relationship between B and C (something like, you cangotofrom C to B without destroying any local variables).So I agree the wording is wrong. I do not agree that it can be repaired editorially. While technically library wording, this is a core language mechanism, so we probably want CWG to look at this and propose a wording change.
Filed a core issue.
This is CWG2361.
- changed the title
[-][csetjmp.syn] Imprecise description of UB[/-][+][csetjmp.syn] CWG 2361: Imprecise description of UB[/+]on Apr 11, 2018 - changed the title
[-][csetjmp.syn] CWG 2361: Imprecise description of UB[/-][+][csetjmp.syn] CWG2361: Imprecise description of UB[/+]on Dec 23, 2021 - changed the title
[-][csetjmp.syn] CWG2361: Imprecise description of UB[/-][+][csetjmp.syn] CWG2361, LWG3652: Imprecise description of UB[/+]on Dec 23, 2021 See also LWG3652.
My understanding is that LWG3652 still doesn't explain how we can "throw an exception at the
longjmpand catch it at thesetjmp"It seems that such UB should be removed in the spirit of CWG2523. But there's still an issue on whether destructor is called on each of these objects.
It's unclear what does the document mean by "replacing". Could be something like "if ... skips stack unwinding ..."