[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
scm_bits_t / scm_ubits_t
From: |
Dirk Herrmann |
Subject: |
scm_bits_t / scm_ubits_t |
Date: |
Fri, 25 May 2001 18:01:31 +0200 (MEST) |
Hello everybody,
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. The name scm_bits_t indicates that we are dealing with
bits, i. e. a raw representation of a value. There are places in guile
that depend on scm_bits_t being signed, but we should rather fix these
instead of introducing another type.
Further, scm_bits_t and scm_ubits_t are now used at a couple of places as
a sort-of replacement of long and unsigned long. I'd like to clarify the
purpose of scm_bits_t: We have introduced scm_bits_t as a type that is
used to access the bit structure of a SCM value, since SCM is a totally
opaque type. That is, scm_bits_t is the result type of SCM_UNPACK, which
converts a SCM value to its raw bit representation. Further, scm_bits_t
is the input type of SCM_PACK which is used to convert a scm_bits_t value
that is the raw bit representation of a scheme value to a SCM value. And,
scm_bits_t is used to store C data in memory cells. For the sake of
cleanliness, other uses of scm_bits_t should be avoided.
Best regards,
Dirk Herrmann
- scm_bits_t / scm_ubits_t,
Dirk Herrmann <=
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/05/25
- 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