[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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]