> On Sep 22, 2016, at 11:16 AM, David Brown <da...@westcontrol.com> wrote:
>
> On 22/09/16 16:57, paul.kon...@dell.com wrote:
>>
>>> On Sep 22, 2016, at 6:17 AM, David Brown <da...@westcontrol.com> wrote:
>>>
>>> ...
>>> Your trouble is that your two pointers, cur and end, are pointing at
>>> different variables. Comparing two pointers that are independent (i.e.,
>>> not pointing to parts of the same aggregate object) is undefined - the
>>> compiler can assume that these two external objects could be anywhere in
>>> memory, so there is no way (in pure C) for you to know or care how they
>>> are related. Therefore it can assume that you will never reach "cur ==
>>> end".
>>
>> Would making them intptr_t instead of pointers fix that?
>>
>
> With care, yes. But I think it still relies on gcc not being quite as
> smart as it could be. This seems to generate working code, but the
> compier could in theory still apply the same analysis:
>
> void rtems_initialize_executive(void)
> {
> uintptr_t cur = (uintptr_t) _Linker_set__Sysinit_begin;
> uintptr_t end = (uintptr_t) _Linker_set__Sysinit_end;
I would not expect the compiler to apply pointer rules for code like this.
(u)intptr_t is an integer type; it happens to be one whose width is chosen to
match the width of pointers on the platform in question, but that doesn't
change the fact the type is integer. For example, it is perfectly valid for an
intptr_t variable to contain values that could not possibly be pointers on a
given platform.
paul
