| Age | Commit message (Collapse) | Author |
|---|
|
* sverker/big-band-bug/ERL-804/OTP-15487:
erts: Fix bug in 'band' of two negative numbers, one big
|
|
Similar bug as for bxor fixed by abc4fd372d476821448dfb9
Ex:
1> io:format("~.16B\n", [-16#1110000000000000000 band (-1)]).
-1120000000000000000
Wrong result for
(-X bsl WS) band -Y.
where
X is any positive integer
WS is erlang:system_info(wordsize)*8*N where N is 1 or larger
Y is any positive integer smaller than (1 bsl WS)
Fix:
The subtraction of 1 (for 2-complement conversion)
must be carried along all the way to the last words.
|
|
The multiplication of two bignums is specially optimized when the two
operands have the same address, because squaring can be done more
efficiently than multiplication of two arbitrary integers. That is,
expressions such as `I * I` will be calculated by squaring the value
of `I`.
The optimized function for squaring would read one word beyond the
end of the bignum in the last iteration of a loop. The garbage
value would never be used. In almost all circumstances that would
be harmless. Only if the read word happened to fall on the start
of an unmapped page would the runtime crash. That is unlikely
to happen because most bignums are stored on a process heap, and
since the stack is located at the other end of the block that the
heap is located in, the word beyond the end of bignum is guaranteed
to be readable.
|
|
|
|
'0 bsl 134217728' would fail with a system limit exception on a 32-bit
BEAM machine, but not on a 64-bit BEAM machine. Smaller values
on the right would always work.
Make erlang:bsl(0, BigNumber) always return 0 to make for consistency.
(The previous commit accidentally did that change for
'0 bsl BigNumber'.)
|
|
* 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
