issue#-188 compiler trap with SYSTEM.VAL

User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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
cfbsoftware
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm
Contact:

Re: issue#-188 compiler trap with SYSTEM.VAL

Post by cfbsoftware »

This sort of information is often best presented in a tabular form as in this example for SQL Server CAST and CONVERT:
lrdatahd.png
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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
User avatar
Robert
Posts: 1024
Joined: Sat Sep 28, 2013 11:04 am
Location: Edinburgh, Scotland

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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.
User avatar
Josef Templ
Posts: 2047
Joined: Tue Sep 17, 2013 6:50 am

Re: issue#-188 compiler trap with SYSTEM.VAL

Post 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
Post Reply