Re: Making 'eq' == 'eql' in bignum branch

[Paul Eggert <eggert@cs.ucla.edu>]

Herring, Davis wrote:
> this is far from the only place in Emacs where what is formally undefined behavior is expected to "do the obvious thing"

Emacs does not rely on undefined behavior for integer arithmetic. Even in Emacs 
26, (abs most-negative-fixnum) yields most-negative-fixnum without doing 
anything undefined at the C level, because (- most-negative-fixnum) fits within 
machine limits and the tagging operation does not overflow.

Although there may be a few places left in Emacs that rely on undefined integer 
behavior, these are now considered bugs and occasionally I try to stamp them out 
by building with gcc -fsanitize=undefined. For example, in Emacs 26 (* 
most-positive-fixnum most-positive-fixnum) returns 1 (the overflowed value) 
without overflowing at the C level.

Emacs *does* rely on undefined behavior when it tags pointers, but that's a 
different kettle of fish.