ports/124985: [patch] devel/dmucs unbreak on 64bits archs

[Erik Trulsson]

On Mon, Jul 07, 2008 at 07:20:17PM +0200, Pietro Cerutti wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> Kostik Belousov wrote:
> | On Mon, Jul 07, 2008 at 06:34:54PM +0200, Pietro Cerutti wrote:
> |> I definitely do not agree. Please note that a pointer is not required to
> |> fit into a long, while it is required to fit into a size_t.
> | I do not think that C99 requires the size_t to be capable of holding
> | the pointer. size_t is only required to hold result of sizeof.
> 
> size_t is required to be of rank equal to or greater than any other
> object you can create from within the C language. This implies that it
> can (i.e., it is required to be able to) hold a pointer type.

Wrong.  There is no requirement in C that there exists *any* integer
type large enough to hold a pointer - and certainly not that size_t
is such a type.

size_t must be large enough to hold the size of any object that the C
implementation allows you to create, but there is no requirement that
you can create an object that occupies the whole memory space.

(E.g. if you had an implementation that did not allow to create
any arrays larger than 4GB or to malloc() more than 4GB at a time, 
then it would suffice to have a 32-bit size_t even if pointers
were 64-bit.  (For older machines make that: 64KB objects, 16-bit size_t
and 32-bit pointers.))


> 
> |
> | It is intptr_t type that shall do it.
> 
> Unfortunately intptr_t is not defined prior to C99, and I still haven't
> got used to use it. Yes, that would be the preferred solution.
> 




-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se