New post
Question
· May 25, 2023

Should numeric overflow be detected during the syntax check?

#Compiler #Testing #InterSystems IRIS

In elder versions of IRIS/Cache numeric overflow was detected during the syntax check: 

USER>w $p($p($zv,") ",2)," ("),!! s txt="-123.45E6789",s(0)=1,s(1)=" if ("_txt_")" zwrite s w !,$compile(s,0,e),!! zwrite e
2021.1.1

s(0)=1
s(1)=" if (-123.45E6789)"
W $P($P($ZV,") ",2)," ("),!! S txt="-123.45E6789",s(0)=1,s(1)=" if ("_txt_")" ZW
RITE s W $COMPILE(s,0,e),!! ZWRITE e
       ^
<MAXNUMBER>

while in IRIS 2022.1 it is not:

USER>w $p($p($zv,") ",2)," ("),!! s txt="-123.45E6789",s(0)=1,s(1)=" if ("_txt_")" zwrite s w !,$compile(s,0,e),!! zwrite e
2022.1.3
 
s(0)=1
s(1)=" if (-123.45E6789)"
0
e=""

A new bug or a new feature?

Product version: IRIS 2022.1
$ZV: IRIS for Windows (x86-64) 2022.1.3 (Build 668U) Fri Apr 7 2023 12:37:55 EDT
Discussion (5)2
Log in or sign up to continue
Steven Hobbs · May 26, 2023

InterSystems changed how <MAXNUMBER> was signaled during conversion from text representation to numeric representation when support for 64-bit IEEE binary floating point was added to Caché.  Textual numbers that overflowed the default ObjectScript decimal representation are converted to 64-bit IEEE binary floating point which supports a much larger range of magnitudes (but about 3 fewer digits of decimal precision.)  When a literal would exceed the magnitude of IEEE floating point, the choice of whether to signal <MAXNUMBER> depends on the run-time $SYSTEM.Process.IEEEError setting since IEEE floating-point overflow can either signal <MAXNUMBER> or it can return an IEEE floating-point infinity.  When the compiler sees a numeric literal that exceeds the finite IEEE number range then the decision to signal an error is delayed until run-time execution so the current $SYSTEM.Process.IEEEError setting can be obeyed.

1 0