Thread
Commits
-
Test ECPG decadd(), decdiv(), decmul(), and decsub() for risnull() input.
- 7b3259bd7cf3 14.16 landed
- 6c1cc35d90c7 13.19 landed
- 216294ba592f 15.11 landed
- 3d57f7cf3005 16.7 landed
- 3637905c3cdf 17.3 landed
- 7819a25cd101 18.0 landed
-
- Fixed Informix compat math functions to cope with the situations
- 757fb0e5a9a6 8.0.0 cited
-
ECPG deccall3 functions vs. risnull() inputs
Noah Misch <noah@leadboat.com> — 2025-01-06T19:27:48Z
When I compiled with -ftrivial-auto-var-init=pattern, ECPG's dec_test reported a diff. Nothing else reported a diff. dec_test calls informix.c numeric functions like decadd() and decmul(). One test operand, decarr[14], is risnull(). When these informix.c functions get an risnull() input, they just return 0 without changing the output parameter. Our ecpg.sgml docs don't discuss this. Applicable Informix doc https://www.ibm.com/docs/en/informix-servers/15.0.0?topic=information-null-values-in-host-variables just says "do not attempt to perform arithmetic", which I take to assign undefined behavior for risnull() input. If someone can easily check how Informix works for this, would you do so? Before commit 757fb0e (2004-03), these functions would rsetnull() the output parameter if given risnull() input. That's like the effect of SQL NULL input to a SQL arithmetic operator. I suspect the change for risnull() input was an unintentional side effect of that commit's mission to make dec*() functions support callers passing the same var as both an input and an output. Two patches attached. The first patch just makes the test clarify what's happening. The second would restore the pre-2004 behavior, but I plan to commit that one only if someone's Informix testing confirms it.