[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_bits_t / scm_ubits_t
From: |
Marius Vollmer |
Subject: |
Re: scm_bits_t / scm_ubits_t |
Date: |
26 May 2001 02:36:02 +0200 |
User-agent: |
Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102 |
Dirk Herrmann <address@hidden> writes:
> due to a recent change, we have a scm_ubits_t type in guile, that is meant
> to represent an unsigned form of scm_bits_t. IMO, this is not a good
> idea: We should rather guarantee, that scm_bits_t itself is already an
> unsigned value.
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.
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.
- scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/05/25
- Re: scm_bits_t / scm_ubits_t,
Marius Vollmer <=
- Re: scm_bits_t / scm_ubits_t, Michael Livshin, 2001/05/25
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/05/26
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/05/30
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/05/31
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/05/31