Re: scm_bits_t / scm_ubits_t

[Dirk Herrmann]

On 1 Jun 2001, Michael Livshin wrote:

> Dirk Herrmann <address@hidden> writes:
> 
> > > [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''.
> > 
> > That's a good suggestion.
> 
> how is that better than the current (in CVS) arrangement where you
> have scm2int, scm2long, scm2size, scm2ptrdiff, scm2short ....?  beats
> the need to manually check the result, I think.
> 
> (will have to add such converters for all the other important integral
>  types, but that's mostly automated and very easy).

Well, at least the u?int2scm solution is very nice.  We don't actually
need all the functions scm_u?short2num, scm_u?int2num, scm_u?long2num,
scm_size2num, scm_ptrdiff2num, scm_u?intptr2num, scm_u?intmax2num.  
Actually, scm_u?intmax2num would be sufficient, and it would be no
performance problem if inlining is used.  Actually, the current macro
magic does exactly the same, namely emulating inlining.

With respect to the other direction, I think the current CVS solution is
somewhat overkill.  It may make sense to provide a certain subset of type
conversions, like for u?short, u?int, u?long, but for the others (ptrdiff,
size, u?intptr), I don't assume that they will be commonly used.  For
those, however, it is good to provide the user with a catch-all fallback
solution as would be offered by u?intmax.  If in some user code it is a
common pattern to do conversions to ptrdiff_t, I don't consider it too big
a burden to have the users define a private scm2ptrdiff function in their
application.

Best regards,
Dirk Herrmann