Arithmetic overflow handling

[fzabkar]

If I add two large 16-bit numbers in FreeBASIC, and if the result is a 17-bit number, then the 17th bit goes into the bit bucket without generating an error message. This is the behaviour that I prefer when I am computing a checksum over a word array.

I am currently maintaining source code written in Visual Basic 6. The author has written a checksum calculation routine which accounts for overflows. He does this by using a 32-bit variable to store the result of each 16-bit addition, and then subtracts 0x10000 from the 32-bit variable whenever there is a 17-bit result.

Does VB6 really differ from FreeBASIC in this respect (overflow handling), or is the author being too careful?

[badidea]

Depends on the application, I would say.
For certain applications it might not be important that an overflow occurs.
If you are sure that your inputs can never cause an overflow, then no problem.
If a bank uses 16-bit numbers for the amount deposited, some would not be happy (others would).
Also, if you detect overflow, what do you do with it? print a warning/error? change your code?

Simple test with unsigned 16-bit:

Code: Select all

dim as ushort a, b
dim as ulong c
a = &hE000
b = &hF000
c = a + b
print hex(a), hex(b), hex(c)
if c and &hffff0000 then
	print "overflow"
	c -= &h10000 'OR: c and= &hffff
	print hex(a), hex(b), hex(c)
end if

[Tourist Trap]

I am currently maintaining source code written in Visual Basic 6. The author has written a checksum calculation routine which accounts for overflows. He does this by using a 32-bit variable to store the result of each 16-bit addition, and then subtracts 0x10000 from the 32-bit variable whenever there is a 17-bit result.

Does VB6 really differ from FreeBASIC in this respect (overflow handling), or is the author being too careful?

I'm not sure I understand your question. In FB it seems that what your example does is done indeed. For instance a byte value of 255 + 1, will result in 0.
I think however that there is no substraction, it's just truncature (ignoring the overflowing bits).
And as far as I know no error code is emitted anywhere.

Code: Select all

dim as ubyte b
b = 255
? b
b += 1
? b
sleep

[counting_pine]

Unlike FB, Visual Basic (up to 6 at least) and Qbasic, will give an error on arithmetic overflow, as opposed to saturating or wrapping.
While this is useful for catching many bugs, I’ve often looked for workarounds to avoid triggering it.

With 16-bit numbers, this isn’t as hard, and I think the best workaround for wrapping around a+b is to do ((a + b) And 65535).
One of a or b must be at least a Long type, converted if necessary, to avoid triggering an error. But to store an nonnegative 16-bit number, it will probably be a Long anyway.

[fzabkar]

Thanks for all the replies. I have discovered that VB6 code defaults to checking for integer overflows and generates an OverflowException when one occurs. This behaviour can be disabled in the compiler options.

I have programmed in QBasic and FreeBASIC, and now I'm trying to get my head around VB6 (although I have done a short course on the subject). What would be nice is if I could use FreeBASIC coding in VB6, but VB6 has some annoying limitations (eg no bitwise right or left shifts).