In C/C++, signed integer overflow is undefined behavior, and some compilers (such as gcc) will optimize away checks like the one that was present in EvalScript; specifically:
int nBegin = ...; int nEnd = nBegin + size; if (nBegin < 0 || nEnd < nBegin)
will get compiled into:
if (nBegin < 0 || size < 0)
This patch changes the overflow check to avoid relying on the behavior of signed integer overflow, by checking for size > INT_MAX - nBegin (and computing nEnd after the check).
In C/C++, signed integer overflow is undefined behavior, and some
compilers (such as gcc) will optimize away checks like the one that
was present in EvalScript; specifically:
int nBegin = ...;
int nEnd = nBegin + size;
if (nBegin < 0 || nEnd < nBegin)
will get compiled into:
if (nBegin < 0 || size < 0)
This patch changes the overflow check to avoid relying on the behavior
of signed integer overflow, by checking for size > INT_MAX - nBegin
(and computing nEnd after the check).
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/30b42fbbae8a3e18d05db0e150c8fc4fbbb21e66 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
OP_SUBSTR is one of the disabled opcodes.
I think it is time to remove all code for the disabled opcodes. If we ever bring them back, we can resurrect the code from git history after writing extensive unit tests and looking for issues like this.
@gavinandresen Agreed. It can't simply be brought back in any case, since they can't just be turned on without it being a hardfork relative to currently deployed nodes. (e.g. they'd have to be brought back inside a script v2 that looked like a NOOP to existing nodes)
@gavinandresen ACK
ACK on removing them. Indeed, all these opcodes are effectively identical to immediate failure anyway, and nothing except a hard fork can change that, and at that point, there is no reason why they should get a meaning identical to what is (was) implemented.