StrToFloat和谁错了：Delphi或ASE / SQL Server

2019年7月27日 264次阅读

最近我发现了一件奇怪的事：结果

var
  d: double;
begin
  d := StrToFloat('-1.79E308');

与ASE和SQL Server通过的字符串值’-1.79E308’转换为float字段类型不同

INSERT INTO my_table (my_float_field) VALUES (-1.79E308)

对于Delphi内存转储是9A BB AD 58 F1 DC EF FF
对于ASE / SQL Server,数据包中的值选择为99 BB AD 58 F1 DC EF FF.

谁错了,服务器还是Delphi？

最佳答案 我们工作的前提是StrToFloat产生最接近的可表示的二进制浮点值到提供的十进制值.

您出现的两个十六进制值是相邻的.您可以看到它们在有效数字中相差1.以下是一些解码这两个值的Python代码：

>>> import struct
>>> struct.unpack('!d', 'ffefdcf158adbb9a'.decode('hex'))[0]
-1.7900000000000002e+308
>>> struct.unpack('!d', 'ffefdcf158adbb99'.decode('hex'))[0]
-1.79e+308

请记住,Python使用最短的可能值来打印浮点值,其中最接近的可表示值是实际值. ffefdcf158adbb99在Python的眼中解码为打印的值为-1.79e 308,足以证明ffefdcf158adbb99是最接近的可表示值.换句话说,Delphi代码给出了错误的答案.

而且,出于好奇,在相反的方向：

>>> hex(struct.unpack('<Q', struct.pack('<d', float('-1.79e308')))[0])
'0xffefdcf158adbb99L'

值得注意的是,32位Delphi编译器产生了ffefdcf158adbb99,但64位Delphi编译器产生了ffefdcf158adbb9a.这是一个明显的缺陷,应该作为错误报告提交给Quality Portal.

点赞