Re: Intervals crash

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

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: cyd@stupidchicken.com,
 > >     emacs-devel@gnu.org
 > > Date: Fri, 24 Sep 2010 17:52:28 +0900
 > > 
 > > Eli Zaretskii writes:
 > > 
 > >  > If you really need the full range of size_t or EMACS_UINT,
 > >  > there's little you can do in practice.
 > > Practically speaking, Emacs doesn't ever *really* need the full
 > > range of size_t, since Lisp can't represent it in a fixnum.  It
 > > might be nice to have a way to store them, but you can use conses
 > > of fixnums, floats, or the occasionally-requested bignums for
 > > that.
 > 
 > I didn't mean in APIs exposed to Lisp.  I meant Emacs internals.

What makes you think I don't understand that?  I will repeat what I
said earlier: *XEmacs internals don't have EMACS_UINT any more*, and
XEmacs works spectacularly better (in the sense of fewer crashes,
which I consider spectacularly bad things to have happen, YMMV), and
is easier to understand.

What's not to like about that?  Yes, I understand a lot of work needs
to be done to get there.  But (unless Emacs has some lingering
Heisencrashes that aren't understood but might be related to
infrequently called APIs that sometimes return negative numbers that
are cast to unsigned, which of course I'm sure it doesn't ;-) there's
no hurry.  Take your time; I'm just suggesting that EMACS_UINT removal
is a worthy long term goal as every such variable is an accident
waiting to happen with no compensating benefits.

That doesn't mean that we don't have unsigneds; of course we do,
because they're part of the POSIX API.  We just don't allow them to
exist in XEmacs proper any longer than it takes to test for overflow
and convert them to EMACS_INT, or to convert from EMACS_INT to
unsigned and pass to the external API.