Re: Intervals crash

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > From: Chong Yidong <cyd@stupidchicken.com>
 > > Date: Thu, 23 Sep 2010 14:23:24 -0400
 > > Cc: emacs-devel@gnu.org
 > > 
 > > I'm getting a crash due to your recent EMACS_UINT change.
 > 
 > Sorry.
 > 
 > > The LENGTH macro in intervals.h:114 has to be able to return a
 > > negative number.  This is probably worth reverting, until you
 > > come up with a proper fix.

 > I'd rather fix it properly.  I replaced all EMACS_UINT with
 > EMACS_INT in intervals.c, it couldn't be worse than int it used
 > before.

You should just do that everywhere.  EMACS_UINT is a bad idea, and
should be avoided.

First, unsigned-ness tends to propagate because of C coercion rules,
which is rarely desired; I've never seen an instance where that it
useful in Emacsen source code.

Second, unsigned integers are basically useless: ((unsigned) 0 - 1) is
not a error, it is a very big number.  This means that declaring a
non-negative variable to be unsigned buys you nothing in terms of
type-checking.  OTOH, the extra bit of precision is almost never of
interest in Emacs work.

Third, the Unix convention of using negative return values to indicate
error states mixes very badly with the first two facts: it's very easy
to inadvertantly turn a flat-out error into a big success.

The conclusion is that unsigneds (eg, size_t's) should be treated the
same way you treat legacy-encoded external text input: hazardous
material that you should convert to some sane internal type as soon as
possible, and to be produced only just before use in external APIs.
As such, there's really no need for EMACS_UINT.

FWIW, when Ben removed all unsigneds not required by external APIs
from XEmacs, not only did he fix two crashes which were associated
with an earlier misguided attempt to use size_t consistently for
non-negative variables, but two other crashes disappeared and have
never been seen again.