[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: scm_bits_t / scm_ubits_t
From: |
Jacques A. Vidrine |
Subject: |
Re: scm_bits_t / scm_ubits_t |
Date: |
Thu, 31 May 2001 23:31:41 -0500 |
User-agent: |
Mutt/1.2.5i |
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''.
- Re: scm_bits_t / scm_ubits_t, Jacques A. Vidrine, 2001/06/01
- Re: scm_bits_t / scm_ubits_t,
Jacques A. Vidrine <=
- 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