· May 25, 2023

Should numeric overflow be detected during the syntax check?

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

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

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
s(1)=" if (-123.45E6789)"

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

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.