Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

David Nelson — Wed, 09 Apr 2008 17:04:29 GMT

This is an excellent examination of the topic. However, the conclusion that the .NET Framework is handling this situation correctly is flawed, for one simple reason:

"Because leading zeroes are always dropped from the non-decimal string representations of numeric values..."

This is wrong!! When representing negative values using binary two's complement, leading zeros are significant, and cannot be dropped. Dropping them changes the value of the number, and therefore the behavior of the Convert.ToString method is wrong. Simply adding a comment to the documentation saying "its wrong on purpose" is not sufficient; the buggy behavior needs to be fixed.

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

Aaron — Wed, 09 Apr 2008 20:53:29 GMT

I’m not sure the previous post is correct. If the leading bits are zero’s and they are dropped then when the number is converted back from binary it will just pad it back out to 32 bits with zeros. This would put bit 31 back as a zero and indicate that the number is positive.

If the original value was negative, then the bit would be a 1 and would not have been trimmed.

So, this is int.maxvlue

01111111111111111111111111111111

This is int.maxvalue with the leading zero missing

1111111111111111111111111111111

And then this is what would happen when it is converted by Convert.Toint32()

01111111111111111111111111111111

The zero would be “assumed” by the conversion process. Thus the sign would end up correct.

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

David Nelson — Thu, 10 Apr 2008 00:12:59 GMT

@Aaron,

You are assuming that the string representation will always be converted back into a number with the same storage size. But this article is about what happens when the binary representation is converted into a number with a different storage size.

Why make the developer jump through all these hoops to correctly convert the binary representation from one size to another, when all you have to do is treat at least one leading zero is significant? Then the binary representation can be counted on to be accurate regardless of how long it is or what the size was of the location where the value was originally stored. In the example from the article, the result of Convert.ToString(number, HEXADECIMAL) would be a string 33 digits long, which would result in an OverflowException, which is exactly what the developer wants.

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

Miral — Fri, 11 Apr 2008 04:31:09 GMT

In ConversionLibrary.ConvertToSignedInteger, wouldn't this comparison make more sense:

// Throw if sign flag is positive but number is interpreted as negative.

if ((!stringValue.Negative) && (number < 0))

throw new OverflowException(String.Format("0x{0} cannot be converted to an Int32.", stringValue.Value));

This way you're not relying on the bit pattern (which actually will cause an implicit widening anyway).

@David,

The only way that preserving the leading digit will help you is if you have a rule to automatically sign-extend that leading digit whenever converting away from a string. And I guarantee you that doing that will break almost every app in the world, since strings frequently come from user input or external data sources that won't contain a leading sign digit anyway.

The problem mentioned in this article only exists if you do have a mismatch in sizes between your string generator and consumer; if due care is taken to use the same types then there isn't a problem. Or at least there wouldn't be a problem if VB joined the Real World and got itself some unsigned types.

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

David Nelson — Fri, 11 Apr 2008 16:21:08 GMT

@Miral,

If there is no leading sign digit, then it isn't a signed number, and a conversion to a signed type is likely to fail anyway. I'm not concerned with that scenario. I am talking about precisely representing a signed number as a string, which can easily be done by treating a leading 0 as significant. If you truncate all of the leading 0s, then you have to carry the original binary length of the number around with the string representation in order to be able to convert it back to a numeric type. Why force developers to take that extra step, when you could just leave a leading 0 and trust that the string representation is always exact, no matter what length it is?

re: Working with Signed Non-Decimal and Bitwise Values [Ron Petrusha]

Dave — Sat, 12 Apr 2008 01:46:35 GMT

I don't think I understand why the Convert.ToInt32 operation is working correctly when the example bit pattern (from the paragraph before the "Accidental Change of Type" section) implies the value -0.

Bit #: 3 2 1

10987654321098765432109876543210

10000000000000000000000000000000

It seems like this specific value is clearly the result of an overflow. (Is -0 legal? If so, why?) However, it would be impossible to say that (int.MaxValue + 2) is or isn't -1 during the conversion, so maybe it makes sense that checking for the specific -0 case is a waste of time.