未初始化的浮点变量，再现不确定的行为

Question

I had to debug some code that was exhibiting transient and sporadic behavior, which ultimately could be attributed to an uninitialized float in a line of initializations, ie:

float a = number, b, c = other_number;

This section of code was rapidly sampling a device over a serial connection and averaging the output over some interval. Every once in a while, the number 2.7916085e+035 would get reported, but otherwise the code worked as intended and the bug was not reproducible.

Since the number was always 2.7916085e+035 , I thought there might have been some issues with the communications handling, or the device itself, but these were ruled out. I was almost ready to blame it on external interference until I finally caught a faulty sample in the debugger.

So, to the question. Can someone postulate the significance of 2.7916085e+035 ? I'm not sure it has any meaning outside of my context, but what bothers me is that this number was essentially unreproducibly reproducible . That is to say, I couldn't replicate the problem reliably, but when it arose, it was always the same thing. From my understanding, uninitialized variables are supposed to be indeterminate. It's worth noting that the issue happened in all different places of program execution, phase, time of day, etc... but always on the same system.

Is there something in the .NET framework, runtime, or operating system that was causing the behavior? This was particularly troublesome to track down because the uninitialized variable always had the same value, when it didn't luckily get set to 0.

Edit: Some context. The code is within a timer with a variable tick rate, so the variables are local non-static members of a class:

if(//some box checked)
{
    switch(//some output index)
    {
        case problem_variable:
        {
            if(ready_to_sample)
            {
               float average;

               for each(float num in readings)
               {
                 average += num;
               }

               average /= readings.Count;
            }
         }
    }
}

The variable in question here would be average . readings is a list of outputs that I want to average. average would be redeclared one time per.... average, which can happen in seconds, minutes, hours, or whenever the condition is met to take an average. More often than not the variable would get 0, but occasionally it would get the number above.

Answer 1

In the common floating-point encodings, 2.7916085e+035 is 0x7a570ec5 as a float and 0x474ae1d8a58be975 as a double, modulo endianness. These do not look like a typical text character string, a simple integer, or a common address. (The low bits of the double encoding are uncertain, as you did not capture enough decimal digits to determine them, but the high bits do not look meaningful.)

I expect there is little information to be deduced from this value by itself.

Answer 2

That double in 64-bit binary translates to

0100011101001010111000011101100010100101100010111110100000000000

or

01111010010101110000111011000101

as a 32-bit float. Nearly all modern processors keep instructions and data separate--especially R/W data. The exception, of course, is the old x86, which is a CISC processor, based on the 4004 from the days when every byte was at a premium, and even minicomputers did not have caches to work with. With modern OS's, however, it is much more likely that, while 4 or 8KB pages were being moved around, a page of instructions was changed without zeroing out the old page.

The double version might be the equivalent to

Increment by 1, where r7 (EDI - extended destination index) is selected

The second, viewed as a float, looks like it would translate to either x86 or x86-64:

How do I interpet this x86_64 assembly opcode?

Answer 3

The value that you see for an uninitialized variable is whatever happens to be in that memory location. It's not random; it's a value that was stored in memory by a previous function call. For example:

void f() {
    int i = 3;
}

void g() {
    int i;
    std::cout << i << std::endl;
}

int main() {
    f();
    g();
    return 0;
}

Chances are, this program (assuming the compiler doesn't optimize out the initialization in f() ) will write 3 to the console.

Answer 4

Floats are a base 2 number system. Because of this there are specific values that can not be accurately saved, and evaluate to an approximation.

Your output is probably giving you a value that specifically gets the same estimation. Try running through some common values that you get from the serial connection and see if you can find the value that is causing you grief. I personally would use a double for something like this instead of floats, especially if you are going to be doing any kind of calculations against those numbers.