Page 2 of 2
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Sat Jun 16, 2018 9:54 am
by Robert
Is that consistent with the PSI, maybe that needs
correcting?
The procedures contained in module SYSTEM are listed in the following table. v stands for a variable. x, y, and n stands for expressions. T stands for a type.
Function procedures
Name Argument types Result type Description
...
VAL(T, x) T, x: any type T x interpreted as of type T
* integer types without LONGINT
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Sat Jun 16, 2018 10:06 am
by Josef Templ
We can add a hint about possible restrictions with respect to different register sets.
The precise rule of what is allowed and what is not allowed is very complicated
and hard to describe in prose text.
- Josef
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Mon Jun 18, 2018 8:43 am
by cfbsoftware
This sort of information is often best presented in a tabular form as in this example for
SQL Server CAST and CONVERT:
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Mon Jun 18, 2018 9:25 am
by Robert
I can't resist posting an interesting case I came across recently:
Code: Select all
VAR
m : LONGINT;
x : REAL;
BEGIN
...
x := SYSTEM.VAL (REAL, m)
This usually works fine, but TRAPs for m = -4503599627370495.
I am NOT claiming this is a bug, although the error report is less than transparent.
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Mon Jun 18, 2018 9:38 am
by Josef Templ
The error message is "undefined real result".
Most probably this specified bit pattern of m is not a valid IEEE floating point representation.
- Josef
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Mon Jun 18, 2018 10:22 am
by Robert
Josef Templ wrote:Most probably this specified bit pattern of m is not a valid IEEE floating point representation.
It is a valid (whatever that means in this context) "signalling NaN". If you include signalling NaNs, all bit patterns are valid.
By way of explanation: -4503599627370496 corresponds to -INF, so this example is the smallest signalling NaN.
SYSTEM.VAL handles non-signalling NaNs perfectly well.
Re: issue#-188 compiler trap with SYSTEM.VAL
Posted: Mon Jun 18, 2018 10:27 am
by Josef Templ
Robert wrote:
It is a valid (whatever that means in this context) "signalling NaN".
By way of explanation: -4503599627370496 corresponds to -INF, so this example is the smallest signalling NaN.
SYSTEM.VAL handles non-signalling NaNs perfectly well.
Doesn't "signalling NaN" mean that it signals an error when it is used?
This is exactly what you observe, a trap.
- Josef