Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.std.c > #1828

Re: C11 6.3.2.3p7 Referenced Type

Show all headers | View raw

On 1/7/2013 01:29, Shao Miller wrote:
> On 1/7/2013 00:07, Wojtek Lerch wrote:
>> On 06/01/2013 11:30 PM, Shao Miller wrote:
>>> On 1/6/2013 22:13, Wojtek Lerch wrote:
>>>>
>>>>    int main( void ) {
>>>>      if ( _Alignof(int) <= _Alignof(float) ) {
>>>>        float f;
>>>>        int n, *p = (int*) &f;
>>>>        if ( p == &n )
>>>>          puts( "They're equal!" );
>>>>      }
>>>>    }
>>>>
>>>> If this program produces output on some implementation, which
>>>> requirement of the standard does the implementation violate?  (Chapter
>>>> and verse please.)
>> ...
>>> If I've followed along correctly, the question is: Is a converted
>>> pointer defined to point to the same object as the original, or only the
>>> result of its conversion back to the original pointer type?
>>
>> Yes.  And if it's the first one, then where does the standard say it?
>>
>>> I don't see why this example should be prohibited.
>>>   'n' is never
>>> accessed, so an implementation could choose to put it in the same place
>>> where 'f' is.
>>
>> The implementation is free to completely optimize them out and not put
>> them anywhere at all, but that does not change the fact that in the
>> abstract machine their addresses must be different.  If I changed the
>> check to "if ( (char*)&f == (char*)&n )", it would be required to return
>> false, regardless of whether f and n are accessed or not.  Of course,
>> any decent implementation will generate the same code that it would if I
>> wrote if(0), without any actual comparing of addresses at runtime.
>>
>
> Agreed.  And of course, you didn't use that 'if'. :)
>
>> How about this then:
>>
>>    float f;
>>    int n, *p = (int*) &f;
>>    char *x = (char*)&f, *y = (char*) p;
>>    if ( x != y ) ...
>>
>> In other words, does the standard guarantee that (char*)(int*)&x, if
>> defined, must be equal to (char*)&x?
>>
>
> (I think you meant to ask about '(char*)(int*)&f' and '(char*)&f', and
> 'n' seems to have lost its relevance.)
>
> I think that example has the same consideration as the last one.  If 'p'
> (or '(int*)&f' can point to an object than than 'f', then '(char*)p' can
> point to the lowest-addressed byte of that other object.  But
> '(float*)p' had better point to 'f' again.
>
> One way this might happen is if, for the values of 'int *' and 'float
> *', pointers are simply indices, and '&f' means "the first float in the
> program" and '&n' means "the first int in the program".  'char *' and
> 'void *' (etc.) might have a greater range of meanings/values.
>

Please allow me to re-phrase:

If this is really permitted for a conforming implementation, one way a 
particularly counter-intuitive implementation might make use of that 
allowance is if, for the values of 'int *' and 'float *', pointers are 
simply indices, and '&f' means "the first float in the program" and '&n' 
means "the first int in the program".  'char *' and 'void *' (etc.) 
might have a greater range of meanings/values.

>    &f              : "First float in the program"
>    x = (char *) &f : "Address such-and-such of first float"
>    (float *) x     : "Address - all floats = First float again"
>
>    p = (int *) &f  : "First int in the program?!"
>    (int *) 1       : "First int in the program" (why not?)
>    y = (char *) p  : "Address such-and-such of first int"
>    (float *) y     : "Address - all floats = Wrong table/segment!"
>    (float *) p     : "First float in the program"
>
> Eep.  This would be scary.
>
>>
>>>   As an implementation, I'd enjoy that kind of freedom, for
>>> conservation of storage.
>>
>> Sure, as long you follow the observable behaviour of the abstract
>> machine.  In the abstract machine, n and f are distinct objects and they
>> don't overlap.
>
> Agreed.  Perhaps there's a mention of "same object" somewhere...
>
> - Shao Miller

Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-04 02:08 -0500
  Re: C11 6.3.2.3p7 Referenced Type Keith Thompson <kst-u@mib.org> - 2013-01-04 08:09 -0800
    Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-04 12:25 -0500
    Re: C11 6.3.2.3p7 Referenced Type lawrence.jones@siemens.com - 2013-01-04 13:47 -0500
      Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-04 14:56 -0500
        Re: C11 6.3.2.3p7 Referenced Type lawrence.jones@siemens.com - 2013-01-04 17:10 -0500
          Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-04 20:34 -0500
  Re: C11 6.3.2.3p7 Referenced Type Wojtek Lerch <wojtek_l@yahoo.ca> - 2013-01-04 23:45 -0500
    Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-05 02:07 -0500
      Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-05 02:16 -0500
    Re: C11 6.3.2.3p7 Referenced Type Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 17:25 -0800
      Re: C11 6.3.2.3p7 Referenced Type Wojtek Lerch <wojtek_l@yahoo.ca> - 2013-01-06 22:13 -0500
        Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-06 23:30 -0500
          Re: C11 6.3.2.3p7 Referenced Type Wojtek Lerch <wojtek_l@yahoo.ca> - 2013-01-07 00:07 -0500
            Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-07 01:29 -0500
              Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-07 02:18 -0500
              Re: C11 6.3.2.3p7 Referenced Type Wojtek Lerch <wojtek_l@yahoo.ca> - 2013-01-10 17:45 -0500
          Re: C11 6.3.2.3p7 Referenced Type Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 22:30 -0800
            Re: C11 6.3.2.3p7 Referenced Type Shao Miller <sha0.miller@gmail.com> - 2013-01-07 01:58 -0500
              Re: C11 6.3.2.3p7 Referenced Type Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 23:16 -0800
        Re: C11 6.3.2.3p7 Referenced Type Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-06 22:02 -0800

csiph-web