| Age | Commit message (Collapse) | Author |
|---|
|
While the existing numeric opcodes are all limited to 4-byte bignum
arguments, new opcodes will need different limits.
|
|
Make sure that chainparams and logging is properly initialized. Doing
this for every test may be overkill, but this initialization is so
simple that that does not matter.
This should fix the travis issues.
|
|
|
|
Also use the new flag as a standard rule, and replace the IsCanonicalPush
standardness check with it (as it is more complete).
|
|
|
|
|
|
Because this class replaces some usages of CBigNum, tests have been added to
verify that they function the same way. The only difference in their usage is
the handling of out-of-range numbers.
While operands are constrained to [-0x7FFFFFFF,0x7FFFFFFF], the results may
overflow. The overflowing result is technically unbounded, but in practice
it can be no bigger than the result of an operation on two operands. This
implementation limits them to the size of an int64.
CBigNum was unaware of this constraint, so it allowed for unbounded results,
which were then checked before use. CScriptNum asserts if an arithmetic
operation will overflow an int64_t, since scripts are not able to reach those
numbers anyway. Additionally, CScriptNum will throw an exception when
constructed from a vector containing more than 4 bytes This mimics the previous
CastToBigNum behavior.
|
