How can I create a minimal testcase that demonstrates the cost of /EHs?

Question

I'm trying to investigate the difference in generated code when I switch Visual Studio 2019 from /EHsc (Structured and C++ exceptions only) to /EHs (also do not assume that extern "C" functions won't throw – ref), but I can't seem to coax VS into providing a useful testcase when I've minimised it.

I'm surprised the following doesn't do it (the assembly in both cases is identical), since the contents of the function referred to by fptr (a possible definition being included in comments for exposition) are unknown to the optimiser.

void foo();

/*void foo()
{
    throw 0;
}*/

extern "C"
void bar(void (*fptr)())
{
    fptr();
}

int main()
{
    try
    {
        bar(&foo);
    }
    catch (...) {}
}

Granted, it knows that any hypothetical exception will be immediately caught, and since with /EHsc the result of this exception propagation is "undefined" per Microsoft, it "appearing to work" is of course a valid outcome. But that's not much help to me here!

So how can I perform this experiment, without introducing different translation units? Ideally I want to be able to come up with a Compiler Explorer snippet for this.

My goal is to prove that permitting extern "C" to throw (or, rather, propagate) C++ exceptions in a well-defined manner does not have a higher runtime cost than I'm willing to accept in trade.

_{Yes, I am aware of general advice not to let exceptions cross module boundaries or flow through third-party C code. Yes, I am doing that anyway. Yes, that's fine in our project!}

Answer 1

The following MCVE may give you some ideas for a test framework. You could easily add more 'thorough' test code, but this will compile and run. Note that, with the /EHsc option set, this warning is generated:

warning C5039: 'FuncTst': pointer or reference to potentially throwing function passed to extern C function under -EHc. Undefined behavior may occur if this function throws an exception.

However, when using /EHs the warning goes away - which suggests at least the possibility of different code generation.

Here's the suggested code:

#pragma warning(disable:4514) // These two lines de-fluff the hundreds of other
#pragma warning(disable:4710) // warning generated when /Wall is used.

#include <iostream>

using pFunc = int(__stdcall*)(int);

extern int __stdcall FuncOne(int p) {
    int answer = 0;
    for (int i = 0; i < p; ++i) answer += i / p; // Possible divide-by-zero
    return answer;
}

extern "C" int __stdcall FuncTst(int i, pFunc fnc) noexcept // Expects noexcept but "FuncOne" can throw!
{
    return fnc(i);
}

int main()
{
    int q;
    std::cout << "Enter test number: ";
    std::cin >> q;
    int z = FuncTst(q, FuncOne);
    std::cout << "Result = " << z << std::endl;
    return 0;
}

Hope it helps! Feel free to offer critique and/or ask for any 'improvements' or explanation.

Note: Although you can't specifically enable the C5039 warning when you compile with (say) \W4, you can force it to flag as an error (though this may be a bit harsh), with:

#pragma warning(error:5039)

Answer 2

This seems a sort of bug on Compiler Explorer, that forces /EHc even if /EHs is explicitly set.

Try to compile this code on some MSVC version with /EHs:

extern "C" void foo() {
    throw 1;
}

static_assert(noexcept(foo()), "");

Surprisingly, the function foo is assumed noexcept, and the compiler output states the reason:

example.cpp (2): warning C4297: 'foo': function assumed not to throw an exception but does (2): note: The function is extern "C" and /EHc was specified

Here you can find this test. You may also see this by adding something like throw 1; in your example.

Nevertheless, you can fix it compiling with /EHc- /EHs (also replace /O3 with /O2, as it is not supported on MSVC), but the output is still the same.

You can find your example, fixed, here. In the /EHc- /EHs case, the output states

cl : Command line warning D9025 : overriding '/EHc' with '/EHc-'

and a static assertion will state that bar is actually not assumed noexcept.