Баг RTL
Alexey Korop
var
R: Double;
s: string;
err: Longint;
begin
{$R+}
s := '1e99999999999999999999999999999999999999999';
val(s, R, err);
writeln(err, ' ', R);
end.
0 1.00000000000000E-0001
Hоги растут IMHO из SYSTEM.PAS, procedure Str2Int:
shl eax,1 // FAST MUL: eax*10
lea eax,[eax+eax*4]
Вот тут порядок спокойно переполняется.
Перед этими строками надо добавить:
cmp eax, 0CCCCCCCh
jg @@Failed
К слову. То, что допускаются числа вроде 1e$FF - это, наверно, тоже баг. А
что 1e$FFFFFFFF=0.1 - это уж точно баг.
С уважением, Alexey.
...В действительности всё совсем не так, как на самом деле.
Vladimir Tkatchenko
>var
> R: Double;
> s: string;
> err: Longint;
>begin
>{$R+}
>s := '1e99999999999999999999999999999999999999999';
>val(s, R, err);
>writeln(err, ' ', R);
>end.
>
>
Открываем Vp21lang.pdf из каталога Doc и читаем:
*Type* *Normalised range* *Digits* *Size(bytes)*
Double 2.23x10-308..1.79x10308 15-16 8
В твоей же строке я насчитал 42(!) значащих цифры. Уж незнаю, у кого баг...
--
With best regards, Vovik
http://zfs.lg.ua/~sands
mailto:sa...@zfs.lg.ua
mailto:sa...@mikroterm.lg.ua
Vladimir Tkatchenko
> В твоей же строке я насчитал 42(!) значащих цифры. Уж незнаю, у кого
> баг...
Пардон, с просонья не разобрался в формате записи, но ты же сколько цифр
пытаешься в порядок упихнуть? Там же всего 10 разрядов!
Alexey Korop
23.01.2007 в 08:29:05 Vladimir Tkatchenko написал к Alexey Korop:
>> var
>> R: Double;
>> s: string;
>> err: Longint;
>> begin
>> {$R+}
>> s := '1e99999999999999999999999999999999999999999';
>> val(s, R, err);
>> writeln(err, ' ', R);
>> end.
>>
>>
VT> Открываем Vp21lang.pdf из каталога Doc и читаем:
VT> *Type* *Normalised range* *Digits* *Size(bytes)*
VT> Double 2.23x10-308..1.79x10308 15-16 8
VT> В твоей же строке я насчитал 42(!) значащих цифры. Уж незнаю, у кого
VT> баг...
У обоих. Во входной строке баг - превышены все разумные пределы. В RTL баг
- вместо того, чтобы отловить входной баг, спокойно выдаёт бредовый результат.
При том, если несколько девяток убрать, то правильно выдаётся ошибка, так что
это однозначно не фича, а баг.
Интересно, что бы ты сказал про библиотеку, которая для ln(-1) молча
выдаст, например, 0? Что, мол, имеет право, ведь логарифм определён только для
положительных чисел?
Vladimir Tkatchenko
Korop wrote:
>В RTL баг - вместо того, чтобы отловить входной баг, спокойно выдаёт бредовый результат. При том, если несколько девяток убрать, то правильно выдаётся ошибка, так что это однозначно не фича, а баг.
>
>
В каком виде выдается ошибка?
>Интересно, что бы ты сказал про библиотеку, которая для ln(-1) молча
>выдаст, например, 0? Что, мол, имеет право, ведь логарифм определён только для
>положительных чисел?
>
>
Интересно, а ты какой результат выдал бы в своей функции? По идее и та и
другая функции должны были вызвать исключительную ситуацию по
переполнению, что служило бы признаком того, что результат (бредовый или
еще какой) не стоит брать во внимание.
Alexey Korop
25.01.2007 в 08:14:18 Vladimir Tkatchenko написал к Alexey Korop:
>> В RTL баг - вместо того, чтобы отловить входной баг, спокойно выдаёт
>> бредовый результат. При том, если несколько девяток убрать, то
>> правильно выдаётся ошибка, так что это однозначно не фича, а баг.
VT> В каком виде выдается ошибка?
В таком, в каком это предусмотрено интерфейсом процедуры Val.
>> Интересно, что бы ты сказал про библиотеку, которая для ln(-1) молча
>> выдаст, например, 0? Что, мол, имеет право, ведь логарифм определён
>> только для положительных чисел?
VT> Интересно, а ты какой результат выдал бы в своей функции? По идее и та
VT> и другая функции должны были вызвать исключительную ситуацию по
VT> переполнению, что служило бы признаком того, что результат (бредовый
VT> или еще какой) не стоит брать во внимание.
А если не фантазировать, а почитать описание Val?