try-finally statement behaviour in MSVC C++

[JonB]

A quick special-interest query from me. Nothing to do with Qt, but addressed to anyone using Microsoft C++ compiler (I don't, so I can't test), just for my interest.

MSVC has a non-standard extension to C++ of (https://msdn.microsoft.com/en-us/library/9xtt5hxz.aspx):

__try {  
   // guarded code  
}  
__finally {  
   // termination code  
} 

I was wondering (idly) how it would handle the following:

int func()
{
    __try {  
        return 1; 
    }  
    __finally {  
        return 2;  
   }
}

What is the return value? Or does the compiler not allow a return statement inside its __finally ?

[aha_1980]

@JonB try yourself: https://godbolt.org/

[JonB]

@aha_1980
Wow, thanks! I didn't know something like that existed, and didn't expect it to offer MSVC. I thought that was commercial (we use it as a paid product in our company), but I guess there's a free one too.

It certainly shows me it compiles OK. However, looking through all the disassembler mov eax, <num> and ret 0 statements I'm unsure what it would actually return if run --- do you know?

[kshegunov]

This comes from the Java world I believe. The idea is to have a handler for the both cases - an exception has occured and it was handled in the catch() (optional) and for when one didn't occur. Both (actually all three) paths would pass through the finally block before continuing on.

[JonB]

@kshegunov
Yes, but the question is: I am deliberately nesting a return statement inside a try...finally where the finally has its own return statement. In this case, which value will the function return, 1 or 2? (I imagine it's the 2 in the __finally, but I wanted to confirm, given that I cannot run this.)

[kshegunov]

1 would be my best guess, but I'm no expert.

[JonB]

@kshegunov
Hmm, but 2 would be my guess, and we can't both be right here (unless it's a quantum computer...)?

[kshegunov]

Glancing at the asm, courtesy of @aha_1980, I'm changing my stance to 2. At least for MSVC 2015 x86_64.

[JonB]

@kshegunov
That sounds more reasonable :)
BTW, what are those ret 0 statements then? Does x86/x64 only use eax for return result, because ret 0 looks like some kind of "return 0" to me?

[kshegunov]

@JonB said in try-finally statement behaviour in MSVC C++:

Does x86/x64 only use eax for return result

Yes.

because ret 0 looks like some kind of "return 0" to me?

Means return to the near address and pop so many bytes (i.e. 0) from the stack.

[JonB]

@kshegunov
Ohhhh, the 0 is "remove bytes from stack", not "pass 0 back to the caller". I would not have guessed that!!!

[kshegunov]

@JonB said in try-finally statement behaviour in MSVC C++:

I would not have guessed that!!!

Yep, it's rather rarely used by the compilers at least from my observations. The usual thing you'd see is just: ret, which is the same as ret 0.