[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: |
10 Jun 2001 19:36:00 +0300 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) |
"Jacques A. Vidrine" <address@hidden> writes:
> On Sun, Jun 10, 2001 at 03:04:09PM +0300, Michael Livshin wrote:
> > size_t is fine for
> > vector lengths, but might not be enough for list and (bit) array
> > lengths.
>
> This may be true [1], but...
>
> > we should use uintptr_t (or unsigned long) for those.
> ^^^^^^^^^
>
> This is wrong. uintptr_t should really only be used to hold pointer
> values. If one is looking for the largest unsigned integer, then it
> would be pretty safe to have configure check for the following, in
> order:
this is not wrong because we don't look for the largest unsigned
integer type (well, in the case of list length, bit-array lengths are
trickier). we are looking precisely for an integer type that has the
same width as a pointer (to be even more precise, same width as a
pointer to cell, but at this point the C standard stops cooperating
;))
> [1] Strictly speaking, size_t could be very small in theory: it only
> needs to be big enough to express the size of a single object. In
> practice, I've never seen a system where it was smaller than
> unsigned long (on i386 sizeof(int)==sizeof(long)).
me neither, but You Never Know (tm).
--
A true Klingon Warrior does not comment his code!
-- Klingon Programmer
- Re: scm_bits_t / scm_ubits_t, (continued)
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/05
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/09
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/09
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/13
- Re: scm_bits_t / scm_ubits_t, Michael Livshin, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/10
- Re: scm_bits_t / scm_ubits_t,
Michael Livshin <=
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Michael Livshin, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/11
- Re: scm_bits_t / scm_ubits_t, Michael Livshin, 2001/06/11
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/11
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/11
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/11
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/13
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/13
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/13