The Wiert Corner – irregular stream of stuff

[WayBack] Delphi “WAT?!” of the day: var v1, v2: Variant; begin v1 := True; v2 := True… shows some interesting code.

The [WayBack] Variant Types (Delphi) – RAD Studio: Variant Type Conversions (and the decimal point/comma handling or rounding issues not documented there) usually kill you and are the most important reason to avoid Variant operations in Delphi.

–jeroen

For my archive, most bugs around UInt64 handling, lots of them in the Windows x64 compiler, all by David Heffernan:

1. [WayBack] Who can guess what value is returned by StrToFloat(‘߀’) if the PUREPASCAL version of StrToFloat is used ……. Make sure that you copy and paste the… – David Heffernan – Google+
   • [WayBack] StrToFloat fails to report invalid floating point numbers in Delphi 64bits – Stack OverflowThis is a defect that is present in all versions of Delphi that use the PUREPASCAL version of StrToFloat. That maps through to InternalTextToExtended which reads the exponent like this:function
   • [Archive.is] Discussion on answer by David Heffernan: StrToFloat fails to report invalid floating point numbers in Delphi 64bits | chat.stackoverflow.com
2. [WayBack] Another day, another bug. This one a rather nasty one in the x64 compiler. Consider this program: {$APPTYPE CONSOLE} uses System.SysUtils; var … – David Heffernan – Google+
3. And my run of bugs continues: https://quality.embarcadero.com/browse/RSP-20351 This program: {$APPTYPE CONSOLE} var D: Double; U64: UInt64; begin … – David Heffernan – Google+
4. [WayBack] Final bug of my day: https://quality.embarcadero.com/browse/RSP-20353 {$APPTYPE CONSOLE} var I: Integer; U64: UInt64; D: Double; begin I := 1;… – David Heffernan – Google+

I also learned that quite a while ago, [Archive.is] System.TFloatSpecial – XE2 API Documentation got introduced.

1: Who can guess what value is returned by

2: Another day, another bug. This one a rather nasty one in the x64 compiler.

Consider this program:

{$APPTYPE CONSOLE}

uses
  System.SysUtils;

var
  D: Double;
begin
  Writeln(fsZero=D.SpecialType);
  Writeln(fsNZero=D.SpecialType);
  D := -D;
  Writeln(fsZero=D.SpecialType);
  Writeln(fsNZero=D.SpecialType);
Readln;
end.

It should output

TRUE
FALSE
FALSE
TRUE

It does so on x86. On x64 it outputs

TRUE
FALSE
TRUE
FALSE

The reason being that Emba implemented floating point negation on x64 by compiling

-d

as

0 - d

Which is a different thing.

The right thing to do is to load the value into an XMM register, and then xor it with 8000000000000000h.

https://quality.embarcadero.com/browse/RSP-20350

That’s three bugs in two days!

3: And my run of bugs continues: https://quality.embarcadero.com/browse/RSP-20351

This program:

{$APPTYPE CONSOLE}
var
  D: Double;
  U64: UInt64;
begin
  D := high(UInt64);
  Writeln(D);

  U64 := high(UInt64);
  D := U64;
  Writeln(D);

  Readln;
end.

should output

1.84467440737096E+0019
1.84467440737096E+0019

but in fact outputs

-1.00000000000000E+0000
1.84467440737096E+0019

I guess the compiler generates code as if the constant value was treated as a signed Int64.

Shout out to +Stefan Glienke for bringing this one to my attention.

I have one more bug that I have seen, but not yet submitted.

Quite amazing what can be found with a little bit of effort. Imagine if the Emba team put in some serious testing effort?

4. Final bug of my day: https://quality.embarcadero.com/browse/RSP-20353

{$APPTYPE CONSOLE}
var
I: Integer;
U64: UInt64;
D: Double;
begin
I := 1;
U64 := $8000000000000000;
D := I * U64;
Writeln(D);

U64 := $7fffffffffffffff;
D := I * U64;
Writeln(D);

Readln;
end.

Under dcc32 all is well, the output is

9.22337203685478E+0018
9.22337203685478E+0018

but under dcc64 it all goes south

-9.22337203685478E+0018
9.22337203685478E+0018

Looks like the compiler authors still haven’t found all the parts of the code that treat UInt64 as though it were Int64.

All these bugs (5 reports, but more bugs) from one simple SO question yesterday about StrToFloat……..