Re: scm_bits_t / scm_ubits_t

[Jacques A. Vidrine]

On Fri, Jun 01, 2001 at 12:44:16AM +0200, Marius Vollmer wrote:
> > Agreed with respect to scm_t_bits.  But, why aren't lengths just
> > size_t variables?  Maybe I am wrong here, but I thought that size_t
> > was a type that resembles the amount of available memory.

ANSI C and  POSIX just specifies size_t as ``Unsigned  integer type of
the result of the sizeof operator.''

> Hmm, could be.  But if that is the case, why isn't size_t good enough
> for holding all pointers?  

On most platforms, it probably is.

> Why did they specify intptr_t?

So that there would be a  signed integer type and an unsigned interger
type with which you are guaranteed the following for any pointer `p':

   (void *)p == (void *)((intptr_t)p)
   (void *)p == (void *)((uintptr_t)p)   

> The
> information I have (from the glibc docs) is that size_t can hold the
> size of all objects that can be allocated by malloc (or some other
> means).  In a segmented architecture, I could imagine that there is
> more memory available in toto than the maximum size of any single
> object.

Or even on a more sophisticated system, I could conceive a programming
environment where  the typical split  between kernel and  user address
space is visible.

> Since we already find intptr_t or define it ourselves, we can also use
> it for the length types.
> 
> But I think you are arguing that introdcuing the special aliases
> scm_t_length and scm_t_ulength is not necessary, right?  If we can
> indeed let them be equal to ssize_t and size_t, then we should avoid
> them, I agree.  But can we?  Jacques?

My  suggestion was  to the  appropriate standard  type (u?intptr_t  or
s?size_t)  directly  in  the  code.  All  POSIX  platforms  will  have
s?size_t of course.  On platforms  that don't (yet) have u?intptr_t, I
think we should typedef these to  a type appropriate for that platform
(both `unsigned long' and `size_t' seem like good guesses to me if you
have nothing else to go on).

But  what does  `scm_length' and  `scm_ulength' need  to mean?   Those
names don't sound as if you  want the property illustrated above (safe
conversion integer<->pointer).  In fact, as  you noted, on a segmented
architecture you  might get  something quite  surprising as  the upper
limit.  Do you  want these to be largest integer  type?  Then there is
u?intmax_t [1] for such.

I'll have to look  at how these are used currently.  I  just got off a
plane, though, and  I don't feel like it tonight  :-) Without looking,
`length' seems to imply something such  as `ssize_t' if we are talking
about memory allocations.

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


[1] Ooh,  won't it be  nice when we  have C99 widely  available?  Then
    scm2u?int and u?int2scm can work for all integer types!

    intmax_t  scm2int(SCM);
    uintmax_t scm2uint(SCM);
    SCM       int2scm(intmax_t);
    SCM       uint2scm(uintmax_t);

    For u?int2scm,  the compiler  will take  care of  promoting types.
    For scm2u?int,  the programmer just  compares the result  with tbe
    appropriate constant.

      int intfunc(...) {
          intmax_t n;
          ...
          n = scm2int(aNumber);
          if (n < INT_MIN || n > INT_MAX) 
                  boom();
          else
                  return n;
      }

   Gee, I wonder if  we could do this now by  defining intmax_t and so
   on  ourselves, or  by using  our own  typedef for  ``biggest native
   integer''.