CodeGear (Borland) "non finito": not properly a form of art (http://www.sandon.it/node/35)

While enabling a Delphi application to connect to its remote server using a TSocketConnection and not only a TDCOMConnection, I found ian ssue while I was returning Int64 data. It worked flawlessy via DCOM, but not via the easier-to-setup socket connection. What was happening? Well, in SConnect.pas there is this declaration:

[delphi]VariantSize: array[0..varLongWord] of Word = (...)[/delphi]

It is used in TDataBlockInterpreter.ReadVariant() to get the data size to be read from the stream the socket connection uses to pass data around:

[delphi]Data.Read(TVarData(Result).VPointer, VariantSize[VType and varTypeMask]);[/delphi]

The problem is that varLongWord is the last identifier supported, and VType is 19 for a Longword value... guess what is it for an Int64 value? 20. While compiling with range checking disabled, the program could raise an AV or worse return some incorrect data. Of course because a variant can hold 64 bit data there were no compiler errors or warnings.

It looks that since the introduction of 64 bit data types noone at Borland/Codegear bothered to update this unit - and I found this bug in Delphi 2007.This is another case of Borland/Codegear "non finito" (unfinished) - keep adding new features but never make the current one work flawlessy - and never fix a release after a few months it was rolled out, so you can force users to buy new releases hoping more bugs have been fixed. And it's getting more and more difficult to keep on using Delphi as long as applications become more complex and customers more demanding - and my current customers are pretty big companies.While Michelangelo's "non finito" has its own beauty, Codegear unfinished work in not a form of art - it's just good for antiacid producers. 


Source URL: http://www.sandon.it/node/35