4

I am handling a legacy code.

To fix some bug, I have to give EHa to some of the files. I tested giving both EHsc and EHa to the whole project when building. This solves my problem but gives warnings saying that compiler is overriding EHs with EHa. (order of options is: /EHsc /EHa) This warning occurs only when files that need EHa is being built. It doesn't appear on source files that only needs EHs.

<name of the file that needs EHa>\cl : warning D9025 : overriding '/EHs' with '/EHa'

My question is, does this warning tell what actually happens? Is EHa applied only on source files that actually need EHa? (Are the other files that do not need EHa built with EHsc?)

Thank you.

Niroshan
  • 2,064
  • 6
  • 35
  • 60

2 Answers2

6

/EHa is the "stronger" setting. It implies /EHsc but ensures that C++ destructors are called even when a non C++ exception is thrown and caught. SEH exceptions in Windows. Just plain /EHsc allows the code generator to optimize the code and omit exception filters when it doesn't see a way for the bracketed code to throw a C++ exception. That kind of optimization cannot work for SEH exceptions, any statement can throw an AccessViolation for example.

You only need /EHa when you use the non-standard __try and __except keywords in your program to catch SEH exceptions. AccessViolation, DivisionByZero, floating point exceptions, interop with language runtimes that use SEH for their own exceptions, etcetera. If you use them then you have to make sure that all your code is compiled with /EHa. Getting that wrong can cause memory leaks when an SEH exception is caught.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • The code uses `set_se_translator()`. And this function is used only on few files. I want to compile files that use that function with EHa and rest with more performance friendly EHsc. Does the current approach do that? thank you – Niroshan Oct 12 '11 at 17:07
  • 1
    The MSDN docs are crystal clear: `You must use /EHa when using _set_se_translator`. A few files doesn't count. The exception filter overhead is *very* small in 32-bit code, none in 64-bit code. Are you micro-optimizing or have you actually *measured*? – Hans Passant Oct 12 '11 at 17:18
  • If the overhead is very small I don't think I need to worry about it. thanks again. But there are few things I want to get clarified. According to what I understood, MSDN is referring to C++ files that use _set_se_translator(). What about the other files that do not use this function? I feel its useless to apply EHa on them. Could you guide me to a good url or a book (I guess its time for me to study the compiler bit deeply) – Niroshan Oct 13 '11 at 05:13
  • "You only need /EHa when you use the non-standard __try and __except keywords in your program to catch SEH exceptions" - this seems *wrong* to me. I always assumed that you need /EHa to catch SEH exceptions with `catch(...)` -- `__except` *itself* shouldn't be influenced by it at all. Of course, potential d'tors won't be run in case of a SEH, but the `__except` filter should still be invoked. – Martin Ba Oct 24 '16 at 08:08
1

Yes, the warning tells you what happens, because what happens might not be what you intended. That's the entire idea behind compiler warnings.

The compiler doesn't know, or care, which files "actually need EHa" (until the file has been compiled, the compiler can't tell anything about the file). It applies the options you tell it to apply. And you tell it to apply both, and it tells you that it interprets this as if you want EHA to be applied.

Specifying every contradictory flag when invoking the compiler does not mean "try every possible combination of compiler options until you find one that works".

jalf
  • 243,077
  • 51
  • 345
  • 550
  • I am not trying every possible combination. My main concern is possible performance decrease that may incur by using EHa. If EHa is applied on every source file, then I am planning on researching for a way to apply EHa on files that actually need it and compile others with EHsc. The only problem is that I'm new to the Visual C++ based build system used here. thank you – Niroshan Oct 12 '11 at 16:59
  • you can open properties for individual files and set the flag differently for those particular files. But I hope you actually benchmarked it before worrying about a *possible* performance decrease. Premature optimization and all that – jalf Oct 13 '11 at 06:59