Re: Intervals crash

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Mon, 27 Sep 2010 11:02:02 +0200
> 
> > We can get rid of almost all of them, if we believe that size_t and
> > EMACS_UINT are always of the same size.
> 
> Why wouldn't we be using size_t when we needed something of size size_t?

We do, as a matter of habit.  What I meant was to use size_t where we
now use EMACS_UINT, because almost all of those places have nothing to
do with Emacs integers.  We simply use EMACS_UINT as a portable
unsigned data type large enough to accommodate both size_t and a
pointer.

> > In any case, I think we cannot get rid of using an unsigned data type
> > in most of the 70+ places we do now, because of one or more of the
> > following reasons:
> >
> >  . the value is a bit mask or a bit map
> 
> We have the assumption of two's complement arithmetic hardwired in a lot
> of other places.  So bit operations should work on signed numbers
> reasonably well.  Possible exception are right shifts when indeed the
> full range of an EMACS_UINT over an EMACS_INT is being employed, but
> then the number will not convert into an Elisp integer readily anyhow,
> so why use EMACS_UINT at all?

I obviously didn't make myself clear: these are _not_ reasons to use
EMACS_UINT, these are reasons why we sometimes need an unsigned
integer data type.

>> >  . the value is a pointer that is subject to bitwise operations
> 
> Why would a pointer be put into an EMACS_UINT?

Again, not into EMACS_UINT, but rather into an unsigned data type.

The reason is, of course, that almost every Lisp_Object is a pointer
in disguise, and alloc.c was why I put this reason in the list.

> >  . the value is an unsigned data type forced by external hardware or
> >    software API
> 
> Again, why an EMACS_UINT rather than the appropriate unsigned data type
> forced by the external hardware?

See above, this isn't about EMACS_UINT.  We will need some unsigned
data type that is portable between 32- and 64-bit architectures.

> If we use this as a Lisp integer

We don't, and I didn't say we should.  I was talking about unsigned
data types that we would need even if we get rid of EMACS_UINT.