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

["Herring, Davis" <herring@lanl.gov>]

> I was reading a blog post on C over/underruns, and I got to this bit:
> 
>         Note that there is no value than can hold 2147483648, so if you
>         negate (int)0x80000000, you get (int)0x80000000 again. That is
>         something to look out for, because it means abs() returns a
>         negative value when fed -2147483648.
> 
> I didn't know that, [...]

You still don't, because C doesn't work that way.  Even writing (int)0x80000000 (on a system with suitably-sized ints) is implementation-defined <https://en.cppreference.com/w/c/language/conversion#Integer_conversions>.  Applying - to it (on almost any system) is overflow and hence undefined behavior <https://en.cppreference.com/w/c/language/operator_arithmetic#Unary_arithmetic>.

Of course, you have observed the "correctness" of this statement, but that's because it has well-defined (if surprising) behavior in (at least) x86 assembly <https://stackoverflow.com/questions/26440463/does-neg-instruction-in-assembly-language-sets-the-overflow-flag> and, formally, that _happened_ to be the manifestation of the undefined behavior (in the C implementation of Emacs).

On the gripping hand, when the compiler can't prove anything about an integer argument, it is reasonable for us to assume that this will be the behavior; this is far from the only place in Emacs where what is formally undefined behavior is expected to "do the obvious thing".  But it's wrong for "a blog post on C" to say that is unconditionally the behavior.

Davis