[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_bits_t / scm_ubits_t
From: |
Michael Livshin |
Subject: |
Re: scm_bits_t / scm_ubits_t |
Date: |
26 May 2001 04:06:28 +0300 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) |
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