Self-assigning result of comparison operation gives incorrect values in LSL VM 2025
in progress
Fizz Savira
The following code snippet generates a one and a zero for my "vis" value shown in the DBG_MSG0 call (is_visible is an argument to the function declared as integer):
// force into a boolean 0/1 value
integer b4 = is_visible;
is_visible = is_visible != 0;
DBG_MSG0(["S1: change_piece_vis", full_piece_id, "vis", is_visible, b4, "link_num", link_num]);
b4 is printing out as zero, while is_visible ends up being one. The "skid marks" that are the result of this action in my scripts look like this:
set_body_flags 8 0 NEW body_vis_flags 7
S1: change_piece_vis 25 vis 1 0 link_num 57
The first skid mark is shows that body flags was indeed updated to have a zero at the relevant position confirming that the change_piece_vis code should be getting a zero value which is what b4 has stored.
So the "is_visible != 0" clause is not generating the right value.
Log In
H
Harold Linden
marked this post as
in progress
Should be fixed in the next release! https://github.com/secondlife/slua/commit/c2124ef47961d1a548f6bd83c3c8fd11049027b8
H
Harold Linden
marked this post as
planned
H
Harold Linden
Thanks for sending this in! A consistent repro case:
```lsl
integer g = 0;
foo(integer arg)
{
arg = arg != 0;
print(arg);
}
default {
state_entry() {
integer l = 0;
l = l != 0;
g = g != 0;
print(l);
print(g);
foo(0);
}
}
```
Currently prints 1, 0, 1 when it should print 0, 0, 0. We were doing some optimizations for comparison operators that aren't correct when the result of the comparison is to be stored in one of the vars used in the expression.