It looks like there are some places where undefined behavior can be invoked from within scripts.
For example, the sum operator in C4AulExec.cpp performs simple signed addition, which has undefined behavior on overflow.
In this particular case it would be trivial to fix by using unsigned integers. (Which is implementation defined behavior, but afaik all relevant compilers do it the same way.)
The compiler likely generates "correct" code anyway, so I'm not sure whether there are any cases where UB can actually be exploited.
So this is more a general question, about whether such UB should be fixed when it is found in the engine, or whether we "expose" it to the user.
For example, the sum operator in C4AulExec.cpp performs simple signed addition, which has undefined behavior on overflow.
In this particular case it would be trivial to fix by using unsigned integers. (Which is implementation defined behavior, but afaik all relevant compilers do it the same way.)
The compiler likely generates "correct" code anyway, so I'm not sure whether there are any cases where UB can actually be exploited.
So this is more a general question, about whether such UB should be fixed when it is found in the engine, or whether we "expose" it to the user.
It does generate the correct code, and there is tests for the fact that it does. (See also #1389 (where I made some stupid comments…))
I'd like for someone to tell me a thing, though… Instead of 21d8a2a, wouldn't it have been better to fix C4Value::operator++ to behave correctly?
I'd like for someone to tell me a thing, though… Instead of 21d8a2a, wouldn't it have been better to fix C4Value::operator++ to behave correctly?
> Which is implementation defined behavior, but afaik all relevant compilers do it the same way.
It's not; arithmetic on an n-bit unsigned integer is defined to be done modulo 2ⁿ per [basic.fundamental]/4.
Yes, but the conversion back to signed integer is implementation defined:
[conv.integral]
3. If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.
[conv.integral]
3. If the destination type is signed, the value is unchanged if it can be represented in the destination type (and bit-field width); otherwise, the value is implementation-defined.
Powered by mwForum 2.29.7 © 1999-2015 Markus Wichitill