issue#-188 compiler trap with SYSTEM.VAL

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

Postby Robert » Sat Jun 16, 2018 9:54 am

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

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

Postby Josef Templ » Sat Jun 16, 2018 10:06 am

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

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

Postby cfbsoftware » Mon Jun 18, 2018 8:43 am

This sort of information is often best presented in a tabular form as in this example for SQL Server CAST and CONVERT:

lrdatahd.png
cfbsoftware
 
Posts: 204
Joined: Wed Sep 18, 2013 10:06 pm

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

Postby Robert » Mon Jun 18, 2018 9:25 am

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

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

Postby Josef Templ » Mon Jun 18, 2018 9:38 am

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

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

Postby Robert » Mon Jun 18, 2018 10:22 am

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

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

Postby Josef Templ » Mon Jun 18, 2018 10:27 am

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

Previous

Return to Resolved (Bugs)

Who is online

Users browsing this forum: No registered users and 1 guest

cron