[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: size_t vs EMACS_INT

From: Paul Eggert
Subject: Re: size_t vs EMACS_INT
Date: Sat, 16 Jul 2011 04:02:32 -0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110516 Thunderbird/3.1.10

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
and <http://www.sei.cmu.edu/library/abstracts/reports/10tn008.cfm>.
Also, we discussed this in Bug#8545; see, for example,

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]