Hi Chris,

there are two Win32 functions, RtlCaptureContext and RtlRestoreContext,
that you may find useful. They work under both 32-bit and 64-bit Windows,
so the code will be portable and you don't need assembly.

Regards,
Peter
https://www.strchr.com

Thanks, Peter, these are new to me. They're a third option I hadn't 
considered until now:

* Runtime: setjmp / longjmp
* Intrinsic: __builtin_setjmp / __builtin_longjmp
* Platform: RtlCaptureContext / RtlRestoreContext

Like in my article, I was able to construct a working C setjmp/longjmp 
implementation out of them which passed my u-config test suite, both in 
GCC and MSVC. I like having the additional option, but in practice it's 
the worst of the three:

* Void return from RtlCaptureContext makes it cumbersome to distinguish 
the first return from later returns. This state must be managed outside 
the CONTEXT by the caller. The very nature of RtlCaptureContext means you 
cannot just wrap it in a function, and so this extra context will likely 
be managed using a macro.

* On x64, CONTEXT is 1232 bytes. That's huge! The GCC intrinsic context is 
just 40 bytes, and it really only uses the first 24 bytes (rip, rsp, rbp).

* The official documentation is incomplete and slightly incorrect. Oddly 
it's more correct in Windows SDK's winnt.h. (Side note: __cdecl is unusual 
for a kernel32.dll export!)

* Mingw-w64 does not mark them with useful GCC function attributes. The 
first is not returns_twice. Not a big deal, but it definitely makes 
volatile more important. The second is not noreturn, leading to false 
warnings, which happened to me. (Maybe there's a case where it *can* 
return? The documentation is unclear.) In practice I'd probably skip the 
winnt.h include and declare them myself with these attributes.

Despite my complaints, this is quite portable across various Windows 
compilers while being CRT-free. That's worth something.