[erlang-questions] Half word emulators and NIFs

[Paul Davis]

On Mon, Jun 27, 2011 at 6:03 AM, Sverker Eriksson
<sverker@REDACTED> wrote:
> Have you tested with a debug built emulator. That may catch faulty NIF
> behaviors earlier. Otherwise if a NIF builds broken terms on the process
> heap it might not be discovered until later when those terms are matched or
> maybe garbage collected.
>
> There is no difference to make NIF's for the halfword emulator. Just use the
> NIF API as intended and don't cheat (make assumptions about
> sizeof(ERL_NIF_TERM) for example).
>
> /Sverker, Erlang/OTP
>

I've reduced this to a failing test case in the NIF API [1].

In the end it boils down to these two functions (notice one is int64,
the other not):

ERL_NIF_TERM
run_test1(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
    return enif_make_int64(env, 1);
}

ERL_NIF_TERM
run_test2(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
    return enif_make_int(env, 1);
}

Test 1 returns a Value V where (V =:= 1) is false, but (V == 1) is
true. The second function returns a value where both comparisons are
true.

Paolo also found that amusingly this bug disappears at 2^27 as shown by:

ERL_NIF_TERM
run_test3(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
    return enif_make_int64(env, 134217727);
}

ERL_NIF_TERM
run_test4(ErlNifEnv* env, int argc, const ERL_NIF_TERM argv[])
{
    return enif_make_int64(env, 134217728);
}

run_test3 returns a value that can't be pattern matched against
134217727 but test 4 returns a value that can be matched against
134217728.

Also, I built R14B03 on Ubuntu 10.04 with this configure:

./configure --enable-smp --enable-threads --enable-m64-build
--without-javac --enable-halfword-emulator

The processors are a pair of dual core Xeon's if that's important at all.

[1] https://github.com/davisp/halfwordtest