[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: size_t & unsigned long
From: |
Michael Livshin |
Subject: |
Re: size_t & unsigned long |
Date: |
11 May 2001 18:22:28 +0300 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Copyleft) |
Dirk Herrmann <address@hidden> writes:
> IMO, we should at least _try_ to be type safe, and also
> use the most restrictive possible types, like prefering unsigned types for
> values that can't be negative.
total agreement here.
> Another point: We have a type scm_sizet (which, IMO, should better be
> renamed to scm_size_t whenver we fell masochist enough for such a change),
> the purpose of which does not seem to be too clearly defined. In which
> situations should we use this type? What is the difference to
> size_t?
it seems to be a compatibility wrapper: on systems that have `size_t'
it is defined as such, on other systems it is defined as `unsigned
long'.
since Guile requires ANSI C for quite some time now, `scm_sizet'
should just be deprecated. as far as Guile cares, `size_t' is
available everywhere.
so how about this: I'll comb the source and change it to use `size_t'
and `ptrdiff_t' in all the appropriate places. I'll also add
`scm_sizet2num', `scm_ptrdifft2num', `scm_num2sizet' &
`scm_num2ptrdiff'.
comments?
do we still want to have `scm_size_t' and `scm_ptrdiff_t' typedefs,
just in case?
--
Hit the philistines three times over the head with the Elisp reference manual.
-- Michael A. Petonic