[erlang-questions] Big band playing

[Mikael Pettersson]

On Fri, Dec 14, 2018 at 4:32 PM Kostis Sagonas <kostis@REDACTED> wrote:
>
> We have been playing with CutEr (https://github.com/aggelgian/cuter), a
> Concolic unit testing tool for Erlang, and discovered the following bug
> in the implementation of bitwise and (band/2) operator:
>
> Erlang/OTP 21 [erts-10.2] [source-2bf2b70] [64-bit] [smp:8:8]
> [ds:8:8:10] [async-threads:1] [hipe] [sharing-preserving]
>
> Eshell V10.2  (abort with ^G)
> 1> (-1299341865233935136534120785510400) band (-1).
> -1299341865233953583278194495062016
>
>
> which is the wrong result, of course.
>
> Most likely, it has existed forever.

Looks like an old bug, I was able to reproduce it with every release
back to R16B03 (R15B03 wouldn't build due to perl errors).

It's a single-bit error where the least significant bit of the most
significant word (in the bignum representation) gets set.  The call
chain in big.c is big_band() -> I_band() -> I_btrail() -> D_add(),
that D_add() gets 1 as initial carry, and that's what's setting the
bit incorrectly.

I might look a little further, but this needs the eyes of someone more
familiar with the bignum code.

/Mikael