cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)

[Ralf Corsepius]

On 05/12/2011 01:23 PM, Sebastian Huber wrote:
> On 05/12/2011 01:10 PM, Peter Dufault wrote:
>>
>> On May 12, 2011, at 6:10 , Sebastian Huber wrote:
>>
>>> No, uintptr_t is the type used by the heap code.
As you might recall, this implementation detail was and still is arguable.

>>>  We work here with addresses
>>> and not sizes of single objects.
>>
>> I had to look up the definition of uintptr_t.  At least according to Wikipedia it's C99 and is defined as:

A better reference can be found here:

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html

>> ====
>> Integers wide enough to hold pointers
>> intptr_t and uintptr_t is a signed and unsigned integer which are guaranteed to hold the value of a pointer. These two types are optional.
>
> To fulfill this we need sizeof(void *)<= sizeof(uintptr_t).

This is guaranteed by uintptr_t's definition (It's uintptr_t's purpose 
to take a "void*").

>> 1. When would address_type not be void *?
>
> Never, I think.
>
>> 2. When would address_size_type not be size_t?
>
> On some systems you may have sizeof(size_t)<  sizeof(void *)?
Theoretically, such cases are imaginable, because both types actually 
are defined by "convention" and not necessarily defined by "hardware".

In practice, in current RTEMS toolchains, size(size_t) == sizeof(void*) 
applies on all targets.

> I don't know an example.
IIRC, this case was common on DOS (far-pointers) and older x86_64/i386 
linux systems (-D_LARGE_FILE_SYSTEM).
Don't fix me on this - This all is too long ago for me to recall all 
details.

Ralf