Re: scm_bits_t / scm_ubits_t

[Dirk Herrmann]

On Fri, 1 Jun 2001, Jacques A. Vidrine wrote:

> 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.

On such architectures guile won't work anyway at the moment.  We are
relying on the fact that the conversions scm_t_bits <-> void* are
working.

> with a uintptr_t.  Besides, it doesn't make  a lot of sense to use the
> representation of a pointer for a length.

Well, values in cells are of the type scm_t_bits.  This is a typedef based
on uintptr_t, because we want to be able to store pointers in cells.  
Since all other values stored in cells therefore have to be also of type
uintptr_t, we know that all lengths of vectors will be covered by that
type.  I agree that the use of uintptr_t for non-pointer values is
confusing, but we have already accepted that confusion by deciding that
uintptr_t shall be used to define scm_t_bits.

> 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.

It is probably impossible to formulate guile's type encoding tricks
cleanly in the current or future C standard anyway.  However, the
suggestion to simply use size_t for string, vector and list lengths is
good, IMO.

Best regards,
Dirk Herrmann