Re: integer overflow in muli instruction

[Jose E. Marchesi]

> On Ubuntu 16.04 (x86_64, with CC="gcc -ftrapv") I get 4 test suite failures.
> One of these is
>
> FAIL:
> /media/develdata/devel/build/poke-0.90/build-64/testsuite/../poke/poke
> killed: 11472 exp34 0 0 CHILDKILLED SIGABRT SIGABRT
>
> To reproduce it:
>
> (poke) atoi ("deadbeef", 16)
>
> In the debugger:
>
> (poke) atoi ("deadbeef", 16)
>
> Thread 1 "poke" received signal SIGABRT, Aborted.
> 0x00007ffff6e2c438 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54      ../sysdeps/unix/sysv/linux/raise.c: Datei oder Verzeichnis nicht 
> gefunden.
> (gdb) up
> #1  0x00007ffff6e2e03a in __GI_abort () at abort.c:89
> 89      abort.c: Datei oder Verzeichnis nicht gefunden.
> (gdb) up
> #2 0x00007ffff7ba43f2 in __mulvsi3 () from
> /media/develdata/devel/inst-x86_64-64/lib/libpoke.so.0
> (gdb) up
> #3 0x00007ffff7b8ab28 in pvm_execute_or_initialize
> (jitter_initialize=56, jitter_initial_program_point=0x7e5028,
>     jitter_original_state=0x632310) at ../../libpoke/pvm.jitter:2242
> 2242        PVM_BINOP (INT, INT, INT, *);
> (gdb) list
> 2237    #
> 2238    # Stack: ( INT INT -- INT INT INT )
> 2239
> 2240    instruction muli ()
> 2241      code
> 2242        PVM_BINOP (INT, INT, INT, *);
> 2243      end
> 2244    end
> 2245
> 2246    # Instruction: muliu
>
> So, apparently the atoi invocation ends up doing a 'muli' VM instruction,
> and this instruction does a signed integer multiplication that overflows.
> Since signed integer overflow is undefined behaviour in ISO C, 'gcc -ftrapv'
> is right in aborting here.
>
> I would suggest to use checked integer multiplication, for example by using
> the macro INT_MULTIPLY_OVERFLOW from intprops.h (Gnulib module 'intprops').

Hm, I totally agree we have to check the overflow condition.

But then, at this point we have to decide what semantics to implement in
Poke when signed overflow happens (in multiplication, division, etc).

Adopting C semantics, and raising a Poke exception seems to be the most
obvious choice...