| Age | Commit message (Collapse) | Author |
|---|
|
* sverker/big-bxor-bug/ERL-450/OTP-14514:
erts: Fix bug in bxor of a big negative number
|
|
Wrong result for
(X bsl WS) bxor Y.
where
X is any negative integer
Y is any integer that does not require more words than X
WS is erlang:system_info(wordsize) or larger
Fix: The subtraction of 1 (for 2-complement conversion)
must be carried along all the way to the last words.
|
|
|
|
|
|
Those clause are obsolete and never used by common_test.
|
|
|
|
|
|
|
|
As a first step to removing the test_server application as
as its own separate application, change the inclusion of
test_server.hrl to an inclusion of ct.hrl and remove the
inclusion of test_server_line.hrl.
|
|
|
|
Bignums are artifically restricted in size. Arithmetic and logical
operations check the sizes of resulting bignums, and turn oversize
results into system_limit exceptions.
However, this check is not performed when bignums are constructed by
binary matching. The consequence is that such matchings can construct
oversize bignums that satisfy is_integer/1 yet don't work. Performing
arithmetic such as Term - 0 fails with a system_limit exception. Worse,
performing a logical operation such as Term band Term results in [].
The latter occurs because the size checking (e.g. in erts_band()) is
a simple ASSERT(is_not_nil(...)) on the result of the bignum operation,
which internally is [] (NIL) in the case of oversize results. However,
ASSERT is a no-op in release builds, so the error goes unnoticed and []
is returned as the result of the band/2.
This patch addresses this by preventing oversize bignums from entering
the VM via binary matching:
- the internal bytes_to_big() procedure is augmented to return NIL for
oversize results, just like big_norm()
- callers of bytes_to_big() are augmented to check for NIL returns and
signal errors in those cases
- erts_bs_get_integer_2() can only fail with badmatch, so that is the
Erlang-level result of oversize bignums from binary matches
- big_SUITE.erl is extended with a test case that fails without this
fix (no error signalled) and passes with it (badmatch occurs)
Credit goes to Nico Kruber for the initial bug report.
|
|
It seems that a tuple fun was used only because erl_eval:expr/3
did not support passing in a real fun at the time that the test
case was originally written.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
