cleaner & greener (was Re: A patch for RTEMS4.10.0 PowerPC heap space initialization)
ralf.corsepius at rtems.org
Thu May 12 12:00:44 UTC 2011
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:
>> 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
More information about the users