Re: scm_bits_t / scm_ubits_t

[Marius Vollmer]

Michael Livshin <address@hidden> writes:

> Marius Vollmer <address@hidden> writes:
> 
> > Moreover, I think I want to reserve judgment about the whole change.
> 
> FWIW, I'll revert the controversial changes within the next two days.
> sorry about the whole thing.

Hmm, yes, if that is easy to do for you, please do so.  However, it is
probably also OK just to fix a few things about that change, without
reverting it completely.

It's good that you did that work.

The main thing to fix as far as I can see it, is that you use
scm_bits_t (scm_ubits_t) as a numerical type.  We should probably just
define a new type that is as large as scm_bits_t and make a signed and
a unsigned variant of it so that it can be used as a numerical type
(or just say that one can stick "unsigned" in front of it).  That type
will be large enough to enumerate all objects that can be represented
by a (packed) scm_bits_t, that is, it is large enough to hold the
length of all possible lists, of all possible vectors, etc.  What
about naming that type scm_length_t?  (And scm_ulength_t).

> the whole mess was motivated by me reading the latest (well, draft)
> ANSI C standard and noticing that `long' is no longer required to be
> the widest integral type...

How do we get at the integral type that is guaranteed to hold all
pointers?