Re: size_t vs EMACS_INT

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

On 07/16/11 00:13, Eli Zaretskii wrote:
> gobs of C programs do that without testing for overflow before each
> addition.  Why should Emacs be different?

A short answer is that Emacs is supposed to be reliable.

A longer answer is that it depends on the context.  If a C program's
values are known to never overflow in practice, or if we know no
compiler will ever use anything but wraparound semantics and the
program works fine with wraparound, or if the program's behavior
doesn't matter all that much, then it's fine if the program does not
test for overflow.  But if the values might overflow, and if the
compiler might not use wraparound semantics (or the program does not
work with wraparound semantics), and if the program is supposed to be
reliable even when given large values, then the program needs to test
for overflow.

For some more details about this issue, please see
<http://www.gnu.org/s/gnulib/manual/html_node/Integer-Properties.html>
and <http://www.sei.cmu.edu/library/abstracts/reports/10tn008.cfm>.
Also, we discussed this in Bug#8545; see, for example,
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8545#105>.

> Also, the fact that the underlying C data type cannot overflow doesn't
> save us from disasters, because calling make_number on the result
> could still "kind of" overflow, when it bit-shifts the value.

Yes, and I plan to fix that porting problem at some point too.  It
won't be that hard, as shifting comes up less often than addition.
For now, though, I would rather focus on issues with standard integer
arithmetic (+ - * /), as these issues are more likely to cause
real-world issues such as the core dump I mentioned in Bug#9079.