aboutsummaryrefslogtreecommitdiffstats
path: root/erts/emulator/test/binary_SUITE.erl
diff options
context:
space:
mode:
authorBjörn Gustavsson <[email protected]>2018-12-12 14:53:40 +0100
committerBjörn Gustavsson <[email protected]>2018-12-13 10:20:41 +0100
commitc5bb52143bd28c8ce34e427dbf7f024b6e6a65e1 (patch)
treea8af26e339a45dbd5d6658d46c119078175c9ae6 /erts/emulator/test/binary_SUITE.erl
parent3825199794da28d79b21052a2e69e2335921d55e (diff)
downloadotp-c5bb52143bd28c8ce34e427dbf7f024b6e6a65e1.tar.gz
otp-c5bb52143bd28c8ce34e427dbf7f024b6e6a65e1.tar.bz2
otp-c5bb52143bd28c8ce34e427dbf7f024b6e6a65e1.zip
Fix reading beyond end of bignum in integer squaring
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.
Diffstat (limited to 'erts/emulator/test/binary_SUITE.erl')
0 files changed, 0 insertions, 0 deletions