Re: GCC/EGCS parser bug

Re: GCC/EGCS parser bug

[Zack Weinberg]

On Fri, 05 Feb 1999 16:03:14 +0100, Joachim Hollman wrote:
>I read that section, and the wording is the same in the old standard
>if I remember correctly.
>
>The reason for this clause is to disambiguate cases like
>
>typedef int a;
>void f(int (a));
>
>However, because of the '*' in front of "func" in
>
>typedef void (*func)(int);
>void f(int i1, void (*func)(void *, void *), int i2)
>                     ^
>the construct (*func) is a direct-declarator, *not* an
>abstract-declarator,
>and "func" can *only* be parsed as an identifier.

So you get past that clause, func is parsed as an identifier, and
then you hit the rules in section 6.2.3:

       [#1] ...Thus,  there are separate name spaces for various categories
       of identifiers, as follows:

         -- label names (disambiguated by the syntax of  the  label
            declaration and use);

         -- the   tags  of  structures,  unions,  and  enumerations
            (disambiguated  by  following  any22)  of  the keywords
            struct, union, or enum);

         -- the members of structures or unions; each structure  or
            union  has  a  separate  name  space  for  its  members
            (disambiguated by the type of the  expression  used  to
            access the member via the . or -> operator);

         -- all  other  identifiers,  called  ordinary  identifiers
            (declared in ordinary  declarators  or  as  enumeration
            constants).

The `ordinary identifiers' bucket catches typedef names and prototype
parameter names, and you have a clash.

zw


>
>Zack Weinberg wrote:
>> 
>> On Fri, 05 Feb 1999 14:03:55 +0100, Joachim Hollman wrote:
>> >I disagree, but I also realize that you get many bug reports and that
>> >you don't have time to give a detailed response to each one.
>> >
>> >As I see it, one of us misinterpret the ANSI standard.
>> >
>> >Don't you think it would be a good idea to ask somebody else on the
>> >egcs/gcc
>> >team to take a close look at this to make sure that it isn't a bug?
>> 
>> Go ahead and repost to egcs-bugs.  However, may I quote a bit of the
>> standard?
>> 
>> C9x CD2, section 6.7.5.3:
>> 
>>        [#7] If, in a parameter declaration, an  identifier  can  be
>>        treated  as  a typedef name or as a parameter name, it shall
>>        be taken as a typedef name.
>> 
>> zw
>

Re: GCC/EGCS parser bug

[Martin v. Loewis]

>        [#1] ...Thus,  there are separate name spaces for various categories
>        of identifiers, as follows:
[...]
>          -- all  other  identifiers,  called  ordinary  identifiers
>             (declared in ordinary  declarators  or  as  enumeration
>             constants).
> 
> The `ordinary identifiers' bucket catches typedef names and prototype
> parameter names, and you have a clash.

If your interpretation was correct, the following program should be
ill-formed:

void foo(int X);
void bar(int X);

since the identifier X is defined twice. However, gcc does not reject
this code. Then why does it reject Joachim's example?

Martin

Re: GCC/EGCS parser bug

[Zack Weinberg]

On Sun, 14 Feb 1999 10:26:33 +0100, "Martin v. Loewis" wrote:
>>        [#1] ...Thus,  there are separate name spaces for various categories
>>        of identifiers, as follows:
>[...]
>>          -- all  other  identifiers,  called  ordinary  identifiers
>>             (declared in ordinary  declarators  or  as  enumeration
>>             constants).
>> 
>> The `ordinary identifiers' bucket catches typedef names and prototype
>> parameter names, and you have a clash.
>
>If your interpretation was correct, the following program should be
>ill-formed:
>
>void foo(int X);
>void bar(int X);
>
>since the identifier X is defined twice. However, gcc does not reject
>this code. Then why does it reject Joachim's example?

X in this example is a prototype parameter both times, but in
Joachim's example it's a typedef name once and a prototype parameter
once.

Like doing

int x;
int x;

versus

int x;
double x;

zw

Re: GCC/EGCS parser bug

[Joern Rennecke]

> >If your interpretation was correct, the following program should be
> >ill-formed:
> >
> >void foo(int X);
> >void bar(int X);
> >
> >since the identifier X is defined twice. However, gcc does not reject
> >this code. Then why does it reject Joachim's example?
> 
> X in this example is a prototype parameter both times, but in
> Joachim's example it's a typedef name once and a prototype parameter
> once.

The scope of X is inside the function parameter list.  Thus, when X is used
the second time, the first use is out of scope, hence no clash.

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> The scope of X is inside the function parameter list.  Thus, when X is used
> the second time, the first use is out of scope, hence no clash.

This is what I thought. Then what about the original example?

typedef void (*func)(int);
void f(int i1, void (*func)(void *, void *), int i2);

Shouldn't the prototype of f open a new scope, shadowing the previous
(global) definition of func? Shouldn't that happen regardless of whether
the previous definition was a typedef or an object?

Martin

Re: GCC/EGCS parser bug

[Joachim Hollman]

After Zack told me that my code wasn't legal C, I posted a
question to comp.lang.c (now also in comp.std.c) with the
subject "typedef name/argument [Is this legal C?]" (started 2/3/99).

Some of the replies were quite good, so why not take a look?

-- Joachim Hollman

"Martin v. Loewis" wrote:
> 
> > The scope of X is inside the function parameter list.  Thus, when X is used
> > the second time, the first use is out of scope, hence no clash.
> 
> This is what I thought. Then what about the original example?
> 
> typedef void (*func)(int);
> void f(int i1, void (*func)(void *, void *), int i2);
> 
> Shouldn't the prototype of f open a new scope, shadowing the previous
> (global) definition of func? Shouldn't that happen regardless of whether
> the previous definition was a typedef or an object?
> 
> Martin

Re: GCC/EGCS parser bug

[Joern Rennecke]

> This is what I thought. Then what about the original example?
> 
> typedef void (*func)(int);
> void f(int i1, void (*func)(void *, void *), int i2);
> 
> Shouldn't the prototype of f open a new scope, shadowing the previous
> (global) definition of func? Shouldn't that happen regardless of whether
> the previous definition was a typedef or an object?

No, because a typedef changes the type of lexical token of the affected
symbol.

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> > This is what I thought. Then what about the original example?
> > 
> > typedef void (*func)(int);
> > void f(int i1, void (*func)(void *, void *), int i2);
> > 
> > Shouldn't the prototype of f open a new scope, shadowing the previous
> > (global) definition of func? Shouldn't that happen regardless of whether
> > the previous definition was a typedef or an object?
> 
> No, because a typedef changes the type of lexical token of the affected
> symbol.

I'm lost. Why doesn't it 'change the type of lexical token' in

typedef void (*func)(int);

void f()
{
  void (*func)(void*,void*);
  func(0,0);
}

And I thought I understood C...

Martin

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> Some of the replies were quite good, so why not take a look?

So it seems the general consensus is that your example is valid C, and
that the comittee specifically tried to address similar cases, and
failed. Back to egcs-bugs.

Regards,
Martin

Re: GCC/EGCS parser bug

[Joe Buck]

Joern:
> > No, because a typedef changes the type of lexical token of the affected
> > symbol.

Martin:
> I'm lost. Why doesn't it 'change the type of lexical token' in
> 
> typedef void (*func)(int);
> 
> void f()
> {
>   void (*func)(void*,void*);
>   func(0,0);
> }

Stroustrup's 3rd edition (I know, it is not the standard) says that
for scoping purposes, function argument names are considered declared
in the outermost block of a function.  So if

void f()
{
   void (*func)(void*,void*);
   func(0,0);
}

succeeds in saying that func is a pointer to a function that takes two
arguments, so does

void f(void (*func)(void*,void*))
{
   func(0,0);
}

regardless of the presence of a typedef.

Re: GCC/EGCS parser bug

[Joern Rennecke]

> This is what I thought. Then what about the original example?
> 
> typedef void (*func)(int);
> void f(int i1, void (*func)(void *, void *), int i2);
> 
> Shouldn't the prototype of f open a new scope, shadowing the previous
> (global) definition of func? Shouldn't that happen regardless of whether
> the previous definition was a typedef or an object?

No, because a typedef changes the type of lexical token of the affected
symbol.

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> > This is what I thought. Then what about the original example?
> > 
> > typedef void (*func)(int);
> > void f(int i1, void (*func)(void *, void *), int i2);
> > 
> > Shouldn't the prototype of f open a new scope, shadowing the previous
> > (global) definition of func? Shouldn't that happen regardless of whether
> > the previous definition was a typedef or an object?
> 
> No, because a typedef changes the type of lexical token of the affected
> symbol.

I'm lost. Why doesn't it 'change the type of lexical token' in

typedef void (*func)(int);

void f()
{
  void (*func)(void*,void*);
  func(0,0);
}

And I thought I understood C...

Martin

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> The scope of X is inside the function parameter list.  Thus, when X is used
> the second time, the first use is out of scope, hence no clash.

This is what I thought. Then what about the original example?

typedef void (*func)(int);
void f(int i1, void (*func)(void *, void *), int i2);

Shouldn't the prototype of f open a new scope, shadowing the previous
(global) definition of func? Shouldn't that happen regardless of whether
the previous definition was a typedef or an object?

Martin

Re: GCC/EGCS parser bug

[Zack Weinberg]

On Sun, 14 Feb 1999 10:26:33 +0100, "Martin v. Loewis" wrote:
>>        [#1] ...Thus,  there are separate name spaces for various categories
>>        of identifiers, as follows:
>[...]
>>          -- all  other  identifiers,  called  ordinary  identifiers
>>             (declared in ordinary  declarators  or  as  enumeration
>>             constants).
>> 
>> The `ordinary identifiers' bucket catches typedef names and prototype
>> parameter names, and you have a clash.
>
>If your interpretation was correct, the following program should be
>ill-formed:
>
>void foo(int X);
>void bar(int X);
>
>since the identifier X is defined twice. However, gcc does not reject
>this code. Then why does it reject Joachim's example?

X in this example is a prototype parameter both times, but in
Joachim's example it's a typedef name once and a prototype parameter
once.

Like doing

int x;
int x;

versus

int x;
double x;

zw

Re: GCC/EGCS parser bug

[Martin v. Loewis]

>        [#1] ...Thus,  there are separate name spaces for various categories
>        of identifiers, as follows:
[...]
>          -- all  other  identifiers,  called  ordinary  identifiers
>             (declared in ordinary  declarators  or  as  enumeration
>             constants).
> 
> The `ordinary identifiers' bucket catches typedef names and prototype
> parameter names, and you have a clash.

If your interpretation was correct, the following program should be
ill-formed:

void foo(int X);
void bar(int X);

since the identifier X is defined twice. However, gcc does not reject
this code. Then why does it reject Joachim's example?

Martin

Re: GCC/EGCS parser bug

[Martin v. Loewis]

> Some of the replies were quite good, so why not take a look?

So it seems the general consensus is that your example is valid C, and
that the comittee specifically tried to address similar cases, and
failed. Back to egcs-bugs.

Regards,
Martin

Re: GCC/EGCS parser bug

[Joe Buck]

Joern:
> > No, because a typedef changes the type of lexical token of the affected
> > symbol.

Martin:
> I'm lost. Why doesn't it 'change the type of lexical token' in
> 
> typedef void (*func)(int);
> 
> void f()
> {
>   void (*func)(void*,void*);
>   func(0,0);
> }

Stroustrup's 3rd edition (I know, it is not the standard) says that
for scoping purposes, function argument names are considered declared
in the outermost block of a function.  So if

void f()
{
   void (*func)(void*,void*);
   func(0,0);
}

succeeds in saying that func is a pointer to a function that takes two
arguments, so does

void f(void (*func)(void*,void*))
{
   func(0,0);
}

regardless of the presence of a typedef.

Re: GCC/EGCS parser bug

[Joachim Hollman]

After Zack told me that my code wasn't legal C, I posted a
question to comp.lang.c (now also in comp.std.c) with the
subject "typedef name/argument [Is this legal C?]" (started 2/3/99).

Some of the replies were quite good, so why not take a look?

-- Joachim Hollman

"Martin v. Loewis" wrote:
> 
> > The scope of X is inside the function parameter list.  Thus, when X is used
> > the second time, the first use is out of scope, hence no clash.
> 
> This is what I thought. Then what about the original example?
> 
> typedef void (*func)(int);
> void f(int i1, void (*func)(void *, void *), int i2);
> 
> Shouldn't the prototype of f open a new scope, shadowing the previous
> (global) definition of func? Shouldn't that happen regardless of whether
> the previous definition was a typedef or an object?
> 
> Martin

Re: GCC/EGCS parser bug

[Joern Rennecke]

> >If your interpretation was correct, the following program should be
> >ill-formed:
> >
> >void foo(int X);
> >void bar(int X);
> >
> >since the identifier X is defined twice. However, gcc does not reject
> >this code. Then why does it reject Joachim's example?
> 
> X in this example is a prototype parameter both times, but in
> Joachim's example it's a typedef name once and a prototype parameter
> once.

The scope of X is inside the function parameter list.  Thus, when X is used
the second time, the first use is out of scope, hence no clash.

Re: GCC/EGCS parser bug

[Zack Weinberg]

On Fri, 05 Feb 1999 16:03:14 +0100, Joachim Hollman wrote:
>I read that section, and the wording is the same in the old standard
>if I remember correctly.
>
>The reason for this clause is to disambiguate cases like
>
>typedef int a;
>void f(int (a));
>
>However, because of the '*' in front of "func" in
>
>typedef void (*func)(int);
>void f(int i1, void (*func)(void *, void *), int i2)
>                     ^
>the construct (*func) is a direct-declarator, *not* an
>abstract-declarator,
>and "func" can *only* be parsed as an identifier.

So you get past that clause, func is parsed as an identifier, and
then you hit the rules in section 6.2.3:

       [#1] ...Thus,  there are separate name spaces for various categories
       of identifiers, as follows:

         -- label names (disambiguated by the syntax of  the  label
            declaration and use);

         -- the   tags  of  structures,  unions,  and  enumerations
            (disambiguated  by  following  any22)  of  the keywords
            struct, union, or enum);

         -- the members of structures or unions; each structure  or
            union  has  a  separate  name  space  for  its  members
            (disambiguated by the type of the  expression  used  to
            access the member via the . or -> operator);

         -- all  other  identifiers,  called  ordinary  identifiers
            (declared in ordinary  declarators  or  as  enumeration
            constants).

The `ordinary identifiers' bucket catches typedef names and prototype
parameter names, and you have a clash.

zw


>
>Zack Weinberg wrote:
>> 
>> On Fri, 05 Feb 1999 14:03:55 +0100, Joachim Hollman wrote:
>> >I disagree, but I also realize that you get many bug reports and that
>> >you don't have time to give a detailed response to each one.
>> >
>> >As I see it, one of us misinterpret the ANSI standard.
>> >
>> >Don't you think it would be a good idea to ask somebody else on the
>> >egcs/gcc
>> >team to take a close look at this to make sure that it isn't a bug?
>> 
>> Go ahead and repost to egcs-bugs.  However, may I quote a bit of the
>> standard?
>> 
>> C9x CD2, section 6.7.5.3:
>> 
>>        [#7] If, in a parameter declaration, an  identifier  can  be
>>        treated  as  a typedef name or as a parameter name, it shall
>>        be taken as a typedef name.
>> 
>> zw
>