On September 22, 2016 5:20:56 PM GMT+02:00, paul.kon...@dell.com wrote:
>
>> 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.

I can't see how it could either.  BTW your testcase contains another fragility, 
the order of two global vars.

Richard.

>       paul


Reply via email to