0

I am compiling a MinGW program on Windows (in this case Windows 8.1) and I want to have signals for floating-point errors to be thrown. For some reason I have to use _controlfp_s to enable these signals (None of the other signals require something like this, only floating point errors for some reason), combined with a call to SetUnhandledExceptionFilter to get the exceptions so I can do things like get a stack trace etc... On the version of Windows that I am compiling/testing on, this isn't a problem. However, apparently older versions of msvcrt.dll (such as the ones on Windows XP for example) do not contain an entry for _controlfp_s, and thus cause the program to crash because it can't find this function in the CRT library.

My objective is to make my program "cross-platform" such that, in the newer versions of windows that I am testing on: _controlfp_s is called correctly and I get signals for floating-point errors, and on older versions like XP, nothing gets called and we go on our merry way without EXCEPTION_FLT_INVALID_OPERATION or EXCEPTION_FLT_DIVIDE_BY_ZERO exceptions getting thrown.. :')

Is this even possible? Is there some other way of doing this that doesn't involve not being able to throw/catch floating-point exceptions?

I've checked SO & Google. MSDN is completely worthless.

K6L2
  • 21
  • 6
  • Use LoadLibrary + GetProcAddress() to call a function that might not be available. Just using _controlfp() is the obvious alternative. The real problem is using libraries that *expect* the FPU to not generate exceptions, they all do. That includes DLLs you never thought of, the ones that get injected on the user's machine. Like shell extensions, anti-malware and cloud storage helpers, etcetera. Don't do it. – Hans Passant Feb 04 '15 at 10:32

1 Answers1

1

If you're coming from the Linux world, it may be a surprise that on Windows there is a clear separation between the OS and installed applications.

"Signals for floating point exceptions" really aren't an OS concern. That's the responsibility of each application, assuming they're even written in a language where that makes sense.

The "msvcrt.dll" on Windows XP isn't the normal Visual Studio version, it's a Windows-internal version. Sure, I said before that Windows doesn't care about the programming language that you use, but it uses C and C++ itself. That's an implementation detail you can't rely on.

MinGW, being minimalist, does rely on whatever library it finds. It may find a MSVCRT which completely lacks the code to generate signals for floating point exceptions (why would an OS need that anyway? Why would Windows need any signal? It's not UNIX.)

I'd advise you to stick to SEH, on all Windows versions. That is the native mechanism, and that will work from XP to 10.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • I think this is major defect with MinGW using the OS MSVCRT dll, it should provide its own runtime – paulm Feb 04 '15 at 12:38
  • That's great and all, but according to sources I have just been researching: SEH is not supported in MinGW. See http://stackoverflow.com/questions/7244645/porting-vcs-try-except-exception-stack-overflow-to-mingw – K6L2 Feb 04 '15 at 21:18
  • @K6L2: It won't do C++ stack unwinding on exceptions, but since the questions is about signals (which are nasty `goto` statements) you don't need stack unwinding anyway. – MSalters Feb 04 '15 at 21:35
  • @MSalters: unfortunately that's what I want so I can print stack traces isn't it? – K6L2 Feb 04 '15 at 23:56
  • @K6L2: No? The stack unwinding problem is finding all the dtors to run. MinGW doesn't tell the OS where those are, so the SEH code can't run them. But you just need the stack frames, not dtor addresses. – MSalters Feb 05 '15 at 00:15
  • @MSalters sigh.. I see. Well I guess this is as good of an answer that I'll ever get. Thanks for the help. – K6L2 Feb 05 '15 at 23:09