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

Groups > comp.std.c > #1824

Re: C11 6.3.2.3p7 Referenced Type

Show all headers | View raw

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.

   &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