Re: scm_bits_t / scm_ubits_t

[Jacques A. Vidrine]

On Fri, Jun 01, 2001 at 11:53:28AM +0200, Dirk Herrmann wrote:
> Thus, for the current time we could define that:
> * string lengths -> size_t

Seems fair enough.

> * vector lengths -> uintptr_t (actually, scm_t_bits, but I'd prefer not to
>   use scm_t_bits for anything else than cell data)
> * list lengths -> uintptr_t

I  don't think  you  want  that.  UINTPTR_MAX  might  be smaller  than
SIZE_MAX.  The range  for uintptr_t needs only be big  enough to point
to any  object.  If  you come  across something funky  like a  Cray or
segmented architecture, you might not  be able to express all integers
with a uintptr_t.  Besides, it doesn't make  a lot of sense to use the
representation of a pointer for a length.

i.e., if it is not used to  hold the representation of a pointer, then
I do not  think it should be  of type u?intptr_t.  By the  way, I also
think  it  is supposed  to  be  safe  to  do integer  arithmetic  with
u?intptr_t [1].

I think using size_t for the  lengths would be appropriate.  You might
also consider uintmax_t or one of the exact-width integer types.

Cheers,
-- 
Jacques Vidrine / address@hidden / address@hidden / address@hidden

[1] The following can cause undefined behavior in C:

      char  buf[128];
      char *end;
      char *p;
  
      end = buf + sizeof(buf);
      p = end + 1;              /* undefined */

    The following is OK:

      char       buf[128];
      char      *end;
      uintptr_t  p;
  
      end = buf + sizeof(buf);
      p = (uintptr_t)end + 1;

    Of course this is  a silly example.  A real use  would be when you
    need to determine an address in  memory before you know whether it
    will be valid to dereference it.