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 try block after replacement would be catched. And as that try block varies it might differ whether non-trival destructors of an automatic storage objects would be invoked or not. So what about explaining the try block? 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 setjmp at B and longjmp at 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 setjmp at B and longjmp at A.

in place of

A setjmp/longjmp call pair has undefined behavior if replacing the setjmp and longjmp by catch
and throw would 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 longjmp and catch it at the setjmp, because execution in the function containing the setjmp has by definition already got past the setjmp. Whatever rule we use needs to take into account a third point C, which is the point within the function evaluation containing the setjmp call at which longjmp is 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 can goto from 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.

See also LWG3652.

My understanding is that LWG3652 still doesn't explain how we can "throw an exception at the longjmp and catch it at the setjmp"

My understanding is that LWG3652 still doesn't explain how we can "throw an exception at the longjmp and catch it at the setjmp"

Yes, that's what CWG2361 is about.

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.