Re: scm_bits_t / scm_ubits_t

[Jacques A. Vidrine]

Thanks for the very good explaination.  One thing that I had missed is
just how overloaded the cell type is.  I have some comments below.

On Mon, Jun 11, 2001 at 08:34:58AM +0200, Dirk Herrmann wrote:
[snip]
> In guile, we have the following situation:  The type of cell entries is
> scm_t_bits, which we define based on uintptr_t.  Why is that?  A cell
> entry must be wide enough to hold a pointer to another cell entry.  This
> is scheme's mechanism to build lists.  Thus, we need a type that is wide
> enough to store pointers.  This leads to our decision to use uintptr_t for
> cell entries, even if there is _no_ pointer information stored in
> there.  (Please note that this is already a kind of misuse with respect
> to your position.)

OK.  Except for uintptr_t and intptr_t, conversion between integer and
pointer types is undefined (except for  the case of the null pointer).
So for this use, the type uintptr_t is practically dictated.

[snip length of vectors, lists, strings]

There are assumptions here that uintptr_t  will be wide enough to hold
the  length of  any of  these.  That's  not strictly  true, though  in
practice that will be the case on sane platforms.

> Summarized:  Michael argues based on the type widths.  He does not take
> any 'intended usage' recommendations into account.  Thus, formally, his
> observations are correct.  But, using uintptr_t for list lengths and for
> vector lengths may be confusing, since it is a somewhat non-conventional
> use of these types.  Thus, according to your position, Michael's type
> suggestions are not 'good style'.  They should work, however.

It seems to me that scm_t_bits begs to be a union.

> The suggestion to use size_t for all length types is for the sake of good
> style, not for the sake of correctness with respect to the guaranteed type
> widths:

I  agree.  To  be precisely  correct,  uintmax_t (but  see [1]  again)
should be used for lengths.

> * It is OK to use size_t to represent string lengths, as long as we
>   don't change the string representation.
> * Using size_t to indicate vector lengths is not strictly accurate
>   (because of bitvectors) but still seems natural, because it matches the
>   assumption that vectors are obtained via malloc.
> * Using size_t for list lengths, well, is questionable, but for 
>   the sake of symmetry with the other length types, it should be OK.  We
>   could also have configure checks that verify that
>   sizeof(size_t)==sizeof(uintptr_t) and otherwise refuse to build guile.

Thanks again for the info.

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

[1] In the  real world where we  don't have C99 compilers  and headers
    yet, you probably want `unsigned long long', or `unsigned long' if
    the former doesn't exist.

    Actually, due to  performance issues, you may  want the equivalent
    autoconf magic for:

        if (sizeof(unsigned long) >= sizeof(uintptr_t))
            typedef unsigned long scm_t_bits;
        else
            typedef unsigned long long scm_t_bits;