It is fairly clear from the surrounding code that these instances were writing
to the wrong destination and, in some cases, reading from the wrong sources. The
effect of this bug was a little slippery as the underlying storage is a union
with `integer` and `floating` occupying the same storage, so this change does
not alter which bytes are stored to. Additionally users rarely left or right
shift within GVPR scripts, so it is unlikely this affected any real world code.
Gitlab: Fixes #2103
- PNG format not available in CMake builds with MinGW
- tclpkg Makefile corrupts CFLAGS #2177
- lneato -? sometimes fails with STATUS_STACK_BUFFER_OVERRUN on Windows #1934
+- expr misinterprets `<<` and `>>` #2103
## [2.50.0] – 2021-12-04
v.integer = v.floating > r.floating;
return v;
case LSH:
- v.floating = (Sflong_t) ((Sfulong_t)v.floating << (Sflong_t)r.floating);
+ v.integer = (Sflong_t) ((Sfulong_t)v.floating << (Sflong_t)r.floating);
return v;
case RSH:
- v.floating = (Sflong_t) ((Sfulong_t)v.floating >> (Sflong_t)r.floating);
+ v.integer = (Sflong_t) ((Sfulong_t)v.floating >> (Sflong_t)r.floating);
return v;
}
break;
v.integer = v.integer != r.integer;
return v;
case LSH:
- v.floating = (double)((Sflong_t)v.floating << (Sflong_t)r.floating);
+ v.integer = (Sflong_t)v.integer << (Sflong_t)r.integer;
return v;
case RSH:
- v.integer = (Sfulong_t)v.floating >> (Sflong_t)r.floating;
+ v.integer = (Sfulong_t)v.integer >> (Sflong_t)r.integer;
return v;
case '<':
v.integer = v.integer < r.integer;