Re: scm_bits_t / scm_ubits_t

[Michael Livshin]

Marius Vollmer <address@hidden> writes:

> Yes.  I agree that having scm_ubits_t is not the right thing.
> scm_bits_t is not a numerical type where it makes sense to talk about
> signedness.
> 
> 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.

> For example, this
> 
>       * list.c (scm_ilength): return a scm_bits_t, not long.
>       some other {int,long} -> scm_bits_t changes.
> 
> seems not quite right.  Either, scm_ilength ought to return ssize_t,
> or if ssize_t has not the right semantics (i.e, being able to
> enumerate all distinct objects pointable to from a `char*', which
> might not be the same as being able to represent the size of every
> possible object), we should define our own type for this.  scm_bits_t
> should be only used for unpacked SCM values, to avoid confusion.  Just
> as Dirk says.

using scm_bits_t is indeed wrong here.

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

-- 
You cannot really appreciate "Dilbert" unless you've read it in the
original Klingon.
                                        -- Klingon Programmer