Reliance on Implementation Details

Recently, I stumbled across an issue in a legacy VB.NET app which didn't appear to make any sense. The issue involved determining the precision of a Decimal which was giving different results for exactly the same value.

First of all, I wrote a quick test to attempt to replicate the problem, which appeared to happen for 0.01:

private decimal expectedDecimalPlaces = 2;
 
[TestMethod]
public void Test2DecimalPoint_WithDecimal_ExpectSuccess()
{
    decimal i = 0.01m;
    int actual = Program.Precision(i);
    Assert.AreEqual(actual, expectedDecimalPlaces);
}

This passed, then I'd noticed in a particular method call the signature was expecting a Decimal, but was instead being supplied a Float (yes option strict was off [1]), meaning the Float was being implicitly converted. Quickly writing a test incorporating the conversion:

 private decimal expectedDecimalPlaces = 2;
 
[TestMethod]
public void Test2DecimalPoint_CastFromFloat_ExpectSuccess()
{
    float i = 0.01f;
    int actual = Program.Precision((decimal)i);
    Assert.AreEqual(actual, expectedDecimalPlaces);
}

Causes the issue:

It seems to think 0.01 is to 3 decimal places!

So what's going on here? How can a conversion affect the result of Precison()? Looking at the implementation, I could see it was relying on the individual bits the Decimal is made up from, using Decimal.GetBits() to access them:

 public static int Precision(Decimal number)
{
    int bits = Decimal.GetBits(number)[3];
    var bytes = BitConverter.GetBytes(bits)[2];
 
    return bytes;
}

The result of Decimal.GetBits() is a 4 element array, of which the first 3 elements represent the bits that go to make up the value of Decimal. However, this method relies only on the fourth set of bits - which represents the exponent. In the first test, the decimal value was 1 with exponent 131072, the failed test had 10 and 196608.

When converting to binary, we see the difference more clearly, I've named them bitsSingle for the failed test and bitsDecimal for the passing test:

bitsSingle 00000000 00000011 00000000 00000000
|\-----/ \------/ \---------------/
| | | |
sign <-+ unused exponent unused
| | | |
|/-----\ /------\ /---------------\
bitsDecimal 00000000 00000010 00000000 00000000
 
NOTE: exponent represents multiplication by negative power of 10

As you can see, the exponent for bitsSingle is 3 (00000011) whereas the exponent for bitsDecimal is 2 (00000010), which represents negative powers of 10.

Looking back at the original numbers, we can see how these both accurately represent 0.01:

bitsSingle has a value of 10, with an exponent of -3 = 10 <sup>3</sup>
bitsDecimal has a value of 1, with an exponent of -2 = 10 -<sup>2</sup>

As you can see, Decimal can represent the same value even though the underlying data differs. Precision() is only relying on the exponent and ignoring the value, meaning it's not taking into account the full picture.

But why is the conversion storing this number differently than when instantiated directly? It just so happens that creating a new Decimal (which uses the Decimal constructor) uses a slightly different logic than that of the cast. So even though the number is correct, the underlying data is slightly different.

This brings us to the point of the article. The big picture here is to remember that you should never rely on implementation details, rather only what can be accessed through defined interfaces, whether that be a webservice, reflection on a class, or peeking into the individual bits of a datatype. Implementation details can not only change, but in the world of software - are expected to.

If you want to play around with the examples above, I've uploaded them to GitHub.

[1]I know it's not okay and there isn't a single reason for this, however as usual with a legacy app, we simply don't have the time / money to explicitly convert every single type in a 20,000 + loc project.