For my archive, most bugs around UInt64 handling, lots of them in the Windows x64 compiler, all by David Heffernan:
- [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
PUREPASCALversion ofStrToFloat. That maps through toInternalTextToExtendedwhich 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
- [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
- [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+
- 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+
- [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
StrToFloat('߀')
if the PUREPASCAL version of StrToFloat is used …….
Make sure that you copy and paste the code above rather than re-typing it.
To spoil the surprise read this: https://stackoverflow.com/a/49736812/
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……..
The Wiert Corner - irregular stream of stuff 