A customer had a DLL would sometimes fail to load into certain clients. Further investigation revealed that it failed to load into programs that had enabled floating point exceptions, perhaps inadvertently. The DLL initialized some global variables to hold convenient values, and one of the values it needed was NaN.

This particular DLL did not use the C++ standard library, so it did not have access to numeric_limits<double>::quiet_NaN(). (And even if it did, those values are not compile-time constants.) Instead, it tried to generate a NaN on its own:

double const NaN = HUGE_VAL * 0;

The gotcha here is that HUGE_VAL is a static global variable in the Microsoft C runtime, so this performs a runtime calculation inside of DLL_PROCESS_ATTACH, and if floating point exceptions are enabled, the NaN-generating calculation causes the exception to be raised, which then causes the loader to treat the DLL as having failed to initialize.

The DLL was precalculating NaN because there was a method that returns NaN to indicate that something isn’t available. They precalculated the value so that that method could return it.

The customer’s solution was to move the NaN-generating calculation into the code that needed it. Unfortunately, that still raises the “invalid calculation” exception in the case where the function wants to report “No value”, which isn’t really a case of an invalid calculation; it’s just a sentinel value.

Instead, the code can generate a NaN at compile time. Everybody wins: There is no exception at DLL load time because there is no code running at DLL load time! It also means that the page containing the NaN variable does not get dirtied, which avoids a copy-on-write charge.