[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_bits_t / scm_ubits_t
From: |
Jacques A. Vidrine |
Subject: |
Re: scm_bits_t / scm_ubits_t |
Date: |
Sun, 10 Jun 2001 12:59:09 -0500 |
User-agent: |
Mutt/1.2.5i |
On Sun, Jun 10, 2001 at 07:36:00PM +0300, Michael Livshin wrote:
> "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
> ;))
I hope I haven't got confused, but reading above I see two things:
1. ``size_t is fine for vector _lengths_, but might not be enough
for list and (bit) array _lengths_.'' (emphasis mine).
2. ``we are looking precisely for an integer type that has the same
width as a pointer''
These are different requirements. I'm suggesting (1) should use
uintmax_t, and that (2) should use uintptr_t. What am I missing?
Cheers,
--
Jacques Vidrine / address@hidden / address@hidden / address@hidden
- Re: scm_bits_t / scm_ubits_t, (continued)
- 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, 2001/06/10
- Re: scm_bits_t / scm_ubits_t,
Jacques A. Vidrine <=
- 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
- Re: scm_bits_t / scm_ubits_t, Rob Browning, 2001/06/14