Hi Michael,
GCC distinguishes between them by context and visibility during semantic
analysis.
They cannot be distinguished during syntactic analysis.
HTH,

Hi, John,

Thanks for replying.
To clarify myself a bit, is my following understanding correct ?

For this case:
int main() {
int foo;
foo abc;
}
The Gcc's grammar does parse it, ie. an "identifier" can follow another
"identifier".
Then in the semantic analysis, gcc checks to make sure the first
identifier "foo" must represent a type. In this case, it is not. So an
error is reported.

Thanks.

Mike

Message
From: "John Love-Jensen" <eljay (AT) adobe (DOT) com>
To: "Michael Gong" <mwgong (AT) cs (DOT) toronto.edu>; "MSX to GCC"
<gcc-help (AT) gcc (DOT) gnu.org>
Sent: Tuesday, January 23, 2007 9:18 AM
Subject: Re: typedef name question

Hi Michael,

GCC distinguishes between them by context and visibility during
semantic
analysis.

They cannot be distinguished during syntactic analysis.

HTH,

--

"Michael Gong" <mwgong (AT) cs (DOT) utoronto.cawrites:

To clarify myself a bit, is my following understanding correct ?

For this case:
int main() {
int foo;
foo abc;
}
The Gcc's grammar does parse it, ie. an "identifier" can follow
another "identifier".
Then in the semantic analysis, gcc checks to make sure the first
identifier "foo" must represent a type. In this case, it is not. So an
error is reported.

I think you may be applying compiler theory to a real world compiler.

A better way to describe what happens would be to say that the lexer
looks up each identifier in the symbol table to see whether it is a
type before the parser proper ever sees it.

A truer way to describe what happens would be to observe that gcc uses
a recursive descent parser, not a grammar.

Ian

I am not sure whether following case is a gcc bug or not :

typedef int foo;

foo foo_fct(int a) {

foo foo; /* line 3: a variable foo with type foo
*/

return (foo)foo; /* line 4: gcc reports syntax error */
}

If gcc could , somehow, figure out the line 3 is a variable declaration,
maybe it should be able to handle line 4 , which is a cast expression.

Regards,

Mike

Message
From: "Ian Lance Taylor" <iant (AT) google (DOT) com>
To: "Michael Gong" <mwgong (AT) cs (DOT) toronto.edu>
Cc: <gcc-help (AT) gcc (DOT) gnu.org>
Sent: Tuesday, January 23, 2007 10:28 AM
Subject: Re: typedef name question

"Michael Gong" <mwgong (AT) cs (DOT) utoronto.cawrites:
>
>To clarify myself a bit, is my following understanding correct ?
>>
>For this case:
>int main() {
>int foo;
>foo abc;
>}
>The Gcc's grammar does parse it, ie. an "identifier" can follow
>another "identifier".
>Then in the semantic analysis, gcc checks to make sure the first
>identifier "foo" must represent a type. In this case, it is not. So
>an
>error is reported.
>
I think you may be applying compiler theory to a real world compiler.

A better way to describe what happens would be to say that the lexer
looks up each identifier in the symbol table to see whether it is a
type before the parser proper ever sees it.

A truer way to describe what happens would be to observe that gcc uses
a recursive descent parser, not a grammar.

Ian

Hi Michael,

Not a bug.

The "foo foo;" introduces the foo variable. the foo variable is introduced, it shadows (hides) the outer symbol identifier.

If you try to move the "typedef int foo;" inside the function, you'll notice that the "foo foo;" causes a compiler error, because you have the identifer "foo" redeclared in that scope.

You are allowed to introduce identifiers in a scope that shadow identifiers outside that scope. Even in the "foo foo;" case, where you are using an outer scope identifier and in the process are introducing a new identifier that shadows that self-same outer scope identifier.

HTH,

Hi Michal,

John (Eljay) Love-Jensen wrote:
You are allowed to introduce identifiers in a scope that
shadow identifiers outside that scope. Even in the
"foo foo;" case, where you are using an outer scope
identifier and in the process are introducing a new
identifier that shadows that self-same outer
scope identifier.

Just a small add-on:

In C++ you can easily test this rule and still access the outer identifier
by explicitly looking it up in global namespace scope. The following
compiles with g++:

// foo is defined in the global namespace
typedef int foo;

foo foo_fct(int a) {
foo foo; /* line 3: a variable foo with type foo */
return (::foo)foo; /* line 4: cast to outer foo */
}

course, this does not work with C.

Daniel