Widening Unsigned Values to 64 Bits
The Problem
The Delphi 8 for .NET compiler released in December 2003 contains a codegen bug that will sign-extend unsigned values when they are promoted to Int64. A large positive 32 bit value such as 2952790015 ($AFFFFFFF) would turn into -1342177281 when assigned to an Int64 variable or parameter.
The Solution
The February 2004 web update to the Delphi 8 compiler fixes this codegen issue. Using the updated compiler, assigning a large positive 32 bit value such as 2952790015 to an Int64 variable or parameter will produce a result of 2952790015 with lots of zeros in front.
The Reason For This Note
Some VCL for .NET core code is not entirely happy with this compiler change. In most of the VCL for .NET sources, Win32 handles are typecast to LongInt before assignment to opaque IntPtr variables. In a few places in VCL, Win32 handles are directly typecast to IntPtr. With the compiler fix applied, these handle assignments to IntPtr would sometimes fail with a runtime arithmetic overflow exception. The IntPtr constructor fails if the Win32 handle value is larger than High(Integer) = 2147483647. Win32 handle values in Windows 2000 and earlier generally don't go that high, but in Windows XP Win32 handles are almost always up there in the upper 32 bit unsigned range.
The Feb04 compiler update does not contain any replacement .DCUIL or .pas files. When you apply the update to your D8 installation, you will still be linking against the VCL for .NET .DCUIL files built with the release compiler. Those .DCUIL files run fine because they're passing sign-extended dwords to IntPtrs. IntPtr is happy with the negative numbers that large positive handle values turn into.
If you apply the Feb04 compiler update and rebuild VCL for .NET from source, you will run into this sporadic arithmetic exception when large positive handle values are passed to IntPtr.
What You Need To Do
The simplest way to avoid running into this IntPtr exception in VCL is to not rebuild the VCL sources. In other words: do nothing. Just install the Feb04 update and Ctrl+F9 as usual.
For you source-heads out there, we've posted updated VCL for .NET source files (a total of 7 files were modified) here
in Code Central for you to download and copy into your VCL for .NET source directories. Then you may Build All to your hearts' content.
For Your Own Code
If your own Delphi source code or Delphi source you purchased from a third party vendor typecasts between unsigned 32 bit integers (such as Win32 handles) and IntPtrs, you should review your use of IntPtr. If you can prove that the unsigned 32 bit data that you're cramming into a signed IntPtr will never exceed the range of signed 32 bit ints, then you don't need to do anything at all. Otherwise (or just to be on the safe side), you should ensure that your code consistently typecasts your unsigned ints to signed ints before sending them to IntPtr. The pattern should look like:
IntPtr(Longint(MyUnsignedValue));
If you consistently use the unsigned UIntPtr with your unsigned values, then you have no issues at all. (We would use UIntPtr for Win32 handles if the Win32 PInvoke accepted them...)
What's Next
These VCL for .NET source code modifications will be included in the next D8 update scheduled for release in March04. Where the February04 update focuses exclusively on compiler and debugger fixes, the March04 update will be broader in scope.
More news as it happens,
Danny Thorpe
Delphi Compiler Architect
Borland Software Corp.
