$ZATRANSFORM() returns correct results in an edge case
Final Release Note
$ZATRANSFORM() returns correct results when a numeric value that has no internal string representation is the first argument and the third argument is 2 or -2, specifying a return value of either the next or previous character in the collation order of the first character of the input value. Previously, this could either return the wrong value or get a SIGSEGV (SIG-11) failure generating a core. This edge case was encountered in our development and test environments and was never reported by a user. [#861 (closed)]
Description
Fuzz testing identified this issue and it turns out to be a regression.
Below is a simple test case demonstrating how r1.30
worked fine when a number (instead of a string) was passed as the first argument to $zatransform
.
There are 2 tests one with the 4th argument being 1 and 0 respectively. In both cases, the returned value is 0 which is right.
YottaDB r1.30 output (note the 0 return values here are incorrect - the correct value is 1)
YDB>write $zatransform(0&1,0,2,1)
0
YDB>write $zatransform(0&1,0,2,0)
0
But with r1.32
, the test where the 4th argument is 1 returned a value of 1 (0 was expected due to r1.30 output but later determined that '1' is the correct value). And the test where the 4th argument is 0 terminated with a SIG-11.
YottaDB r1.32 output
YDB>write $zatransform(0&1,0,2,1)
1
YDB>write $zatransform(0&1,0,2,0)
%YDB-F-KILLBYSIGSINFO1, YottaDB process 61109 has been killed by a signal 11 at address 0x00007F65B3F32620 (vaddr 0x0000000000000000)
%YDB-F-SIGMAPERR, Signal was caused by an address not mapped to an object
In my understanding, this is a regression due to the 0b63ce10 changes.
Draft Release Note
$ZATRANSFORM() operates correctly when a numeric value that has no internal string representation is used as the first argument and the 3rd argument is 2 or -2 meaning we want to return either the next or previous character in the collation order of the first character of the input value. Previously, this could either return the wrong value or get a SIGSEGV (sig-11) failure generating a core. This issue was found as a result of fuzz-testing.