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

Groups > comp.std.c > #1877 > unrolled thread

Unimportant but amusing question

Back to article view | Back to comp.std.c

Contents

  Unimportant but amusing question Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-26 09:19 -0800
    Re: Unimportant but amusing question lawrence.jones@siemens.com - 2013-01-26 17:21 -0500
      Re: Unimportant but amusing question Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-28 10:46 -0800
        Re: Unimportant but amusing question Bart van Ingen Schenau <bart@ingen.ddns.info.invalid> - 2013-01-29 10:06 +0000
        Re: Unimportant but amusing question "Derek M. Jones" <derek@_NOSPAM_knosof.co.uk> - 2013-01-29 12:45 +0000

#1877 — Unimportant but amusing question

Consider the following program:

    int x = 1;

    int
    main( int argc, char *argv[] ){
        int x;
        extern int x;
        x = 0;
        {  extern int x;  x = 2; }
        return  x;
    }

Which of these choices best describes the program:

   A. Constraint violation
   B. Undefined behavior
   C. Defined behavior
   D. Strictly conforming
   E. Proof that God exists

Please explain your answer.


Hint:  Read 6.2.2 p4 before answering.

[toc] | [next] | [standalone]

#1878

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Consider the following program:
> 
>     int x = 1;
> 
>     int
>     main( int argc, char *argv[] ){
>         int x;
>         extern int x;
>         x = 0;
>         {  extern int x;  x = 2; }
>         return  x;
>     }
> 
> Which of these choices best describes the program:
> 
>    A. Constraint violation
>    B. Undefined behavior
>    C. Defined behavior
>    D. Strictly conforming
>    E. Proof that God exists
> 
> Please explain your answer.
> 
> 
> Hint:  Read 6.2.2 p4 before answering.

I'd say A. 6.7p3:

	If an identifier has no linkage, there shall be no more than
	one declaration of the identifier (in a declarator or type
	specifier) with the same scope and in the same name space....

That trumps 6.2.2p4 for the two declarations of x in the outer-most
block of main. Since they're in the same scope, no hiding is involved.
-- 
Larry Jones

Everybody's a slave to routine. -- Calvin

[toc] | [prev] | [next] | [standalone]

#1879

lawrence.jones@siemens.com writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Consider the following program:
>> 
>>     int x = 1;
>> 
>>     int
>>     main( int argc, char *argv[] ){
>>         int x;
>>         extern int x;
>>         x = 0;
>>         {  extern int x;  x = 2; }
>>         return  x;
>>     }
>> 
>> Which of these choices best describes the program:
>> 
>>    A. Constraint violation
>>    B. Undefined behavior
>>    C. Defined behavior
>>    D. Strictly conforming
>>    E. Proof that God exists
>> 
>> Please explain your answer.
>> 
>> 
>> Hint:  Read 6.2.2 p4 before answering.
>
> I'd say A. 6.7p3:
>
> 	If an identifier has no linkage, there shall be no more than
> 	one declaration of the identifier (in a declarator or type
> 	specifier) with the same scope and in the same name space....
>
> That trumps 6.2.2p4 for the two declarations of x in the outer-most
> block of main. Since they're in the same scope, no hiding is involved.

Certainly that's a plausible argument.  However, 6.2.2 p4 can be
read as saying the linkage for this identifier is not no linkage but
rather external linkage ("if the prior declaration __specifies__ no
linkage [my emphasis], then the identifier has external linkage").
If 'x' in the two declarations are different identifiers then 6.7p3
doesn't apply;  if these are the same identifier, then 6.2.2p4
overrides the linkage for the one identifier and makes it be
external linkage, in which case 6.7p3 again doesn't apply.

Don't get me wrong, I'm confident your interpretation is what was
intended.  But just from reading the text that conclusion isn't
the only plausible one, or even necessarily the most likely one.
I know some versions (sorry, don't know which ones) of gcc accept
the above program under -std=c99 -pedantic-errors, and with no
complaint.

[toc] | [prev] | [next] | [standalone]

#1880

On Mon, 28 Jan 2013 10:46:25 -0800, Tim Rentsch wrote:
 
> Certainly that's a plausible argument.  However, 6.2.2 p4 can be read as
> saying the linkage for this identifier is not no linkage but rather
> external linkage ("if the prior declaration __specifies__ no linkage [my
> emphasis], then the identifier has external linkage").

It could be read that way, but that reading is contrary to 6.2.2/1 
and /2, which essentially state that identifiers with different linkage 
never refer to the same object.
And nowhere is it specified that the linkage given in a prior declaration 
can be changed in a latter declaration.
6.2.2/4 essentially states that, if there is a prior declaration for an 
object or function that this declaration also can refer to, then it does 
so with the same linkage as the prior declaration. If there is not, this 
declaration refers to an entity with external linkage.
As a declaration of an identifier with no linkage always refers to a 
unique entity, no other declarations can refer to it.

> If 'x' in the two
> declarations are different identifiers then 6.7p3 doesn't apply;  if
> these are the same identifier, then 6.2.2p4 overrides the linkage for
> the one identifier and makes it be external linkage, in which case 6.7p3
> again doesn't apply.

They are declarations for the same identifier (as their names are spelled 
identically), but both declarations refer to different entities.
6.7/3 does apply, because it is two declarations for the same identifier. 
Your interpretation of 6.2.2/4 does not work, because the second 
declaration can't override the linkage specified in the first 
declaration. It means that the second declaration must refer to a 
different object.

Bart van Ingen Schenau

[toc] | [prev] | [next] | [standalone]

#1881

Tim,

On 28/01/2013 18:46, Tim Rentsch wrote:
> lawrence.jones@siemens.com writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>>> Consider the following program:
>>>
>>>      int x = 1;
>>>
>>>      int
>>>      main( int argc, char *argv[] ){
>>>          int x;
>>>          extern int x;
>>>          x = 0;
>>>          {  extern int x;  x = 2; }
>>>          return  x;
>>>      }
>>>
>>> Which of these choices best describes the program:
>>>
>>>     A. Constraint violation
>>>     B. Undefined behavior
>>>     C. Defined behavior
>>>     D. Strictly conforming
>>>     E. Proof that God exists
>>>
>>> Please explain your answer.
>>>
>>>
>>> Hint:  Read 6.2.2 p4 before answering.
>>
>> I'd say A. 6.7p3:
>>
>> 	If an identifier has no linkage, there shall be no more than
>> 	one declaration of the identifier (in a declarator or type
>> 	specifier) with the same scope and in the same name space....

This only applies to identifiers in file or function prototype scope.

>> That trumps 6.2.2p4 for the two declarations of x in the outer-most
>> block of main. Since they're in the same scope, no hiding is involved.
>
> Certainly that's a plausible argument.  However, 6.2.2 p4 can be
> read as saying the linkage for this identifier is not no linkage but
> rather external linkage ("if the prior declaration __specifies__ no
> linkage [my emphasis], then the identifier has external linkage").
> If 'x' in the two declarations are different identifiers then 6.7p3
> doesn't apply;  if these are the same identifier, then 6.2.2p4
> overrides the linkage for the one identifier and makes it be
> external linkage, in which case 6.7p3 again doesn't apply.

The first sentence of 6.2.2p4 is partially about preventing the
following second x from changing the linkage of the first x:

{
int x;
    {
    extern int x;  // Don't want this x change linkage of first x
...

6.2.2p5 says that:

int x;

is treated as-if it were declared:

extern int x;

If 6.2.2p4 had said "... explicitly specifies ..." I think you would
have a point, but I think ".. specifies ..." here can be taken to
include the implicit specifies.

I am intrigued to know how you think the behavior could be anything
other than undefined?

[toc] | [prev] | [standalone]

Back to top | Article view | comp.std.c

csiph-web