Union here follows a common pattern, which in turn is a recognition of the fact that language standard doesn't guarantee meaningful outcome of cast between pointer to data and pointer to function, or vice versa. Or rather that it's specified to be implementation-defined. Even though direct, union-less cast should work as expected with Win32 compilers, it doesn't actually prohibit them to issue a warning. And even though they don't issue warning, it's not inappropriate to adhere to pattern that is guaranteed to be warning-free.

@dot-asm Thank you very much for your detailed explanation! Now I see why a union is used here. I pushed another commit. This time I use a flag variable to track whether we have a cached result in the function pointer, which I think is warning-free and probably easier to understand.

Allow me to be more explicit. It's firm -1 from me. Suggested alternative is explicitly thread unsafe. One can argue that original is not exactly thread-safe in conventional sense, but it works in practice because value returned by GetProcAddress is constant. Worse that can currently happen is that GetProcAddress is executed twice, while worse that can happen in this merge result request is crash.

I totally overlooked thread safety. Sorry! Now I move is_first_time = 0; after GetProcAddress, so now f_isservice is guaranteed to have the right value when the second thread bypasses GetProcAddress.

Maybe I am wrong again, but now I feel my latest proposed code is slightly better in thread safety than the original code. For the original one, there is a very tiny possibility that it causes a NULL dereference. It can occur if after thread A sets p to -1, thread B sets f to 0 at Line _OPENSSL_isservice.f = GetProcAddress(...). Then before thread B sets the union value back to -1, thread A executes (*_OPENSSL_isservice.f) ();, which results in null dereference.

My proposed code doesn't have this issue because f_isservice only has two possible values: NULL or a valid address, and it's impossible to change back to NULL after it's set to a valid address.

Right. Compiler can still generate right code, but we may not assume that it does. However! For same reason we may not assume that compiler compiles code that is using two variables, one being kind of synchronization flag, correctly. In other words, having single "self-synchronizing" variable is the only viable approach. Sorry about delay...

I see. Thanks for explanation again!

But you don't want to fix it? I mean there formally is problem, just two variables is not right approach...

But I can't think of a better way to implement it with one variable.