SET lvn=$FNUMBER() leaves an undefined lvn undefined if $FNUMBER() encounters an error
Final Release Note
An undefined local variable that is the target of an assignment of a [FNUMBER()](https://docs.yottadb.com/ProgrammersGuide/functions.html#fnumber) (e.g., SET X=FNUMBER(y)) which encounters a runtime error leaves the local variable undefined. Previously, the local variable was assigned the value 0. This was only encountered in the development environment, and was never reported by a user. [#830 (closed)]
Description
This is something I noticed as part of code review of sr_port/op_fnfnumber.c
. I have a local variable x
that is undefined at the start. And then invoke a set x=$fnumber(...)
command. The $fnumber()
invocation errored out. But as a side effect the value of x
became defined to the value 0
. I expected x
to stay undefined at the end of $fnumber()
because of the error.
YDB>zwrite x
%YDB-E-LVUNDEF, Undefined local variable: x
YDB>set x=$fnumber("abcd","PT")
%YDB-E-FNARGINC, Format specifiers to $FNUMBER are incompatible: "PT"
YDB>zwrite x
x=0
This seems to be a regression in the upstream GT.M V6.3-001 release. Not sure if there was a correctness reason for that change. The comment below seems to talk about an optimization, not a correctness issue.
$ git show tags/V6.3-001 sr_port/op_fnfnumber.c
commit dab2fc114c3940f01ca8db9e3156d4514a390e70 (tag: V6.3-001)
diff --git a/sr_port/op_fnfnumber.c b/sr_port/op_fnfnumber.c
index 3768fd17..998115ea 100644
--- a/sr_port/op_fnfnumber.c
+++ b/sr_port/op_fnfnumber.c
.
.
+ /* if the dst will be different than the src we'll build the new value in the string pool and repoint dst there,
+ * otherwise, dst will anyway become the same as src, therefore we can safely use dst as a "temporary" copy of src
+ */
+ *dst = *src;
Therefore I am tempted to undo that change and keep dst
untouched until we are about to return from op_fnfnumber()
. But don't want to make that change right away just in case. So creating an issue to see if there are any comments.