On Fri, 14 Apr 2023 at 11:07, Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> In the latest Standard we have:
>
> "The function signature longjmp(jmp_buf jbuf, int val) has more
> restricted behavior in this document. 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 objects with
> automatic storage duration. A call to setjmp or longjmp has undefined
> behavior if invoked in a suspension context of a coroutine."
>
> So let's say we have:
>
> extern void Some_Library_Func( void (*)(void) );
>
> jmp_buf jb;
>
> void JumpBack(void)
> {
> longjmp(jb,1);
> }
>
> int main(void)
> {
> setjmp(jb);
>
> Some_Library_Func( JumpBack );
> }
>
> We would really want an assurance that the function,
> Some_Library_Func, won't put an object on the stack that has a
> non-trivial destructor. Maybe a function attribute could ensure this?
>
> extern void SomeOtherFunc(void);
>
> [[trivial_dtors]] void Some_Library_Func( void (*)(void) )
> {
> std::string s; // COMPILER ERROR: cannot
> // put an object with an non-trivial
> // constructor on the stack
>
> SomeOtherFunc(); // COMPILER ERROR: cannot
> // call another function that has
> // not been marked as trivial_dtors
> }


Yeah, well. No. Convince your tooling vendor to give you a way to
detect this. It's far too obscure, to the point of being
rare as unicorns, for the committee to spend time on it.