Uninitialized floating point variables can be deadly

Raymond Chen


A colleague of mine related to me this story about uninitialized
floating point variables.
He had a function that went something like this,
simplified for expository purposes.
The infoType parameter specified which piece of
information you’re requesting,
and depending on what you’re asking for,
one or the other of the output parameters may not contain a
meaningful result.

BOOL GetInfo(int infoType, int *intResult, double *dblResult)
int intValue;
double dblValue;

switch (infoType) {
intValue = …;

dblValue = …;

*intResult = intValue;
*dblResult = dblValue;


After the product shipped, they started geting crash reports.
This was in the days before Windows Error Reporting,
so all they had to work from was the faulting address,
which implicated the line
*dblResult = dblValue.

My colleague initially suspected that dblResult
was an invalid pointer, but a search of the entire code base
ruled out that possibility.

The problem was the use of an uninitialized floating point
Unlike integers, not all bit patterns are valid for use as
floating point values.
There is a category of values
known as signaling NaNs,

SNaN for short
which are special “not a number” values.
If you ask the processor to,
it will keep an eye out for these signaling NaNs
and raise an “invalid operand” exception when one
is encountered.
(This, after all, is the whole reason why it’s called a signaling

The problem was that, if you are sufficiently unlucky,
the leftover values in the memory assigned to the
dblValue will happen to
have a bit pattern corresponding to a SNaN.
And then when the processor tries to copy it to
dblResult, then exception is raised.

There’s another puzzle lurking behind this one:
Why wasn’t this problem caught in internal testing?
We’ll learn about that next time.

Raymond Chen
Raymond Chen

Follow Raymond   


Comments are closed.