[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_bits_t / scm_ubits_t
From: |
Michael Livshin |
Subject: |
Re: scm_bits_t / scm_ubits_t |
Date: |
01 Jun 2001 13:07:40 +0300 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) |
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).
--
I'm on a seafood diet -- I see food and I eat it. -- anonymous
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/01
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/05
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/09
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/09
- Re: scm_bits_t / scm_ubits_t, Dirk Herrmann, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Marius Vollmer, 2001/06/13
- Re: scm_bits_t / scm_ubits_t, Michael Livshin, 2001/06/10
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/10