Rocket U2 | UniVerse & UniData

 View Only

 [uv/UDO] long integer handling

Manu Fernandes's profile image
PARTNER Manu Fernandes posted 02-07-2024 05:58

hello folks,

I receive an json like this 

      "number": {
        "decimalPlaces": "none",
        "displayAs": "number",
        "maximum": 1.7976931348623157E+308,
        "minimum": -1.7976931348623157E+308

when I perform the udoRead ; I get no problem to read it .

number.decimalPlaces    string none
number.displayAs        string number
number.maximum          number 179769313486232000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
number.minimum          number -179769313486232000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

but when I perform the udoWrite I get a crash

Abnormal termination of UniVerse.
Fault type is 11.  Layer type is BASIC run machine.
Fault occurred in BASIC program IN.SPO at address 4db0.

If someone have a suggestion to handle it ? 

many thanks


Mark Sapp's profile image


Question - how many digits in that number.maximum data  (LEN)  ?

Henry Unger's profile image
PARTNER Henry Unger

Those might be NaN values.

See for more information about floating point numbers. Note that the maximum value is near the upper limit for a 64 bit floating point number, which is 

Manu Fernandes's profile image
PARTNER Manu Fernandes

Hi Mark, Henry.

The len(number.maximum) is 310 as expected 

Yes, it's a 64bit float number ; provided by Sharepoint/site's Columns definition. 

the problem occurs when I try to serialize the values with udoWrite

I try it on uv /win and I get the same result ... 

read ok
U2 exception handler...
Generating exception log file C:\U2\UV\minidump\exception_31132_0209_114243.txt...
Unhandled Exception raised at address 0xE6810F90 : Access violation.  Attempted to read from address 0xFFFFFFFF.
Exception file: C:\U2\UV\minidump\exception_31132_0209_114243.txt
Min dump file: C:\U2\UV\minidump\u2dump_31132_0209_114243.dmp

I attach a little prog to test , if you want try on your system. 


Manu Fernandes's profile image
PARTNER Manu Fernandes

the prog

Attachment  View in library
Manu Fernandes's profile image
PARTNER Manu Fernandes

so, I read the BASIC doc and I read 

All numeric data is represented internally either as floating-point numbers with the full range of values supported by the system’s floating-point implementation, or as integers. On most systems the range is from 10-307 through 10+307 with 15 decimal digits of precision

so, When I get the maximum property ; I get a rounded value to 15 digits and zeros... 

but, sometime the udoWrite works and I read a strange value ; is it a 'false positive' ; capacity overflow memory read worked ?

read ok
read number ok
max type=3, value<179769313486232000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000>  len=309   is num()=1
write ok {
        "number":       {
                "decimalPlaces":        "none",
                "displayAs":    "number",
                "maximum":      179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368,
                "minimum":      -179769313486231570814527423731704356798070567525844996598917476803157260780028538760589558632766878171540458953514382464234321326889464182768467546703537516986049910576551282076245490090389328944075868508455133942304583236903222948165808559332123348274797826204144723168738177180919299881250404026184124858368

I choose to replace the value '1.7976931348623157E+308' by str('9',15) via change(json, '1.7976931348623157E+308', str('9',15)) before udoRead.


Steve Wingfield's profile image
ROCKETEER Steve Wingfield

Hi Manu,

I verified the crash you found here on my windows UV 11.3.  Would you mind creating a support ticket for this, so we can have the issue referenced back to you? 

Thanks for finding this,
Steven Wingfield
Principal Software Engineer
Rocket Software

Doug Averch's profile image
PARTNER Doug Averch

We have seen this problem as well. We just quote the number so that it get processed as a string in UDO. UDO processing removes the quotes so the data is stored in U2 as a string.

Posted: 02-10-2024 10:40

Manu Fernandes's profile image
PARTNER Manu Fernandes

Hello Steve,

I'll escalate trough my support channel.

As basic support from 10-307 through 10+307 with 15 decimal I'll suggest udoREAD  return a error when 'out of  capacity' occurs.

In these case, the value provider is MS-Graph/Sharepoint/Lists/Columns defn. 

 As a workarround, I do json=change(json, '1.7976931348623157E+308', 2^63) 

Thank you all.