Re: EMACS_INT vs int for range checking

[Eli Zaretskii]

> Date: Sat, 26 May 2012 12:05:48 -0700
> From: Paul Eggert <address@hidden>
> CC: address@hidden
> 
> Yes, but the current test does not reliably do that.  On a 64-bit host
> with 32-bit int it's possible, for example, that bidi_mirror_char can
> return a garbage value.

If that garbage passes the [0..MAX_CHAR] test, it's garbage that the
bidi reordering engine and the rest of redisplay can live with.  Why
should we abort in that case?

> This is because assigning an out-of-int-range value to an 'int'
> results in undefined behavior.

How can that undefined behavior be any worse than aborting??

> If it's the EMACS_INT that's annoying, how about this further patch?
> It shortens and clarifies the source code and fixes the portability problem.

I will only accept such a test as an eassert.  This code is in the
innermost loop of the Emacs display engine, so doing all that juggling
in an optimized build _for_every_character_we_display_ is unacceptable.