C grammar for direct-declarator question

[Remco van Engelen]

Hello,

I have a question regarding the ISO C grammar. The syntax of a
direct-declarator reads (section A.2.2, page 413 in my copy; the (R1)
is just to 'name' the rule for later reference):

(R1)
direct-declarator:
identifier
"(" declarator ")"
direct-declarator "[" type-qualifier-list? assignment-expression? "]"
direct-declarator "[" static type-qualifier-list?
assignment-expression "]"
direct-declarator "[" type-qualifier-list "static"
assignment-expression "]"
direct-declarator "[" type-qualifier-list? "*" "]"
direct-declarator "(" parameter-type-list ")"
direct-declarator "(" identifier-list? ")"

I can left-factor this rule into:

(R2)
direct-declarator:
( identifier
| "(" declarator ")"
)
( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
| "(" parameter-type-list ")"
| "(" identifier-list? ")"
)*

Without changing the grammar (I think thats correct, right?).

The semantics of declarations states that in a valid C program, a
function may never return a function or an array type, and an array may
not contain a function type. What I am wondering is if this means that
I can further rewrite the grammar rule for direct-declarator to read:

(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Regards

Remco van Engelen

 

[Michael Mair]

Hello,

I have a question regarding the ISO C grammar. The syntax of a
direct-declarator reads (section A.2.2, page 413 in my copy; the (R1)
is just to 'name' the rule for later reference):

(R1)
direct-declarator:
identifier
"(" declarator ")"
direct-declarator "[" type-qualifier-list? assignment-expression? "]"
direct-declarator "[" static type-qualifier-list?
assignment-expression "]"
direct-declarator "[" type-qualifier-list "static"
assignment-expression "]"
direct-declarator "[" type-qualifier-list? "*" "]"
direct-declarator "(" parameter-type-list ")"
direct-declarator "(" identifier-list? ")"

I can left-factor this rule into:

(R2)
direct-declarator:
( identifier
| "(" declarator ")"
)
( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
| "(" parameter-type-list ")"
| "(" identifier-list? ")"
)*

Without changing the grammar (I think thats correct, right?).

The semantics of declarations states that in a valid C program, a
function may never return a function or an array type, and an array may
not contain a function type. What I am wondering is if this means that
I can further rewrite the grammar rule for direct-declarator to read:

(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Plenty:
Start from
,---
#include <stdio.h>

typedef int (*T_ReturnsInt) (void);

static int foo (void)
{
return 42;
}

static T_ReturnsInt bar (int baz)
{
return foo;
}

int main (void)
{
int qux = bar(0)();
printf("%d\n", qux);
return 0;
}
`---

You can then work your way through arrays of function pointers,
returned pointers to arrays etc. and arrive at
a = (b(i)[c(i)])(i)[0];
and other fun things.

Cheers
Michael

 

[Guest]

(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Plenty:
[...]
int qux = bar(0)();

bar(0)() is an expression, not a declarator.

 

[Michael Mair]

(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Plenty:
[...]
int qux = bar(0)();

bar(0)() is an expression, not a declarator.

You are right -- I did not really look at it and my fingers coded
before I thought. Thanks for the correction; a _real_ example not
covered by (R3):
int (* (*a)(int))[5];

-Michael

 

[Guest]

Remco van Engelen schrieb:

(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Plenty:
[...]
int qux = bar(0)();

bar(0)() is an expression, not a declarator.

You are right -- I did not really look at it and my fingers coded
before I thought. Thanks for the correction; a _real_ example not
covered by (R3):
int (* (*a)(int))[5];

Actually, that is covered too. It is of the form
"(" declarator ")" "[" assignment-expression "]"
regardless of the fact that <declarator> contains more parentheses.

 

[Michael Mair]

Michael Mair wrote:

Remco van Engelen schrieb:


(R3)
direct-declarator:
( identifier
| "(" declarator ")"
)
( ( "[" type-qualifier-list? assignment-expression? "]"
| "[" static type-qualifier-list? assignment-expression "]"
| "[" type-qualifier-list "static" assignment-expression "]"
| "[" type-qualifier-list? "*" "]"
)*
| ( "(" parameter-type-list ")"
| "(" identifier-list? ")"
)
)

Without getting syntax errors on valid C programs ofcourse.

So, the real question is: is there a valid C program which is accepted
in a grammar in which I use rule R1, but which would be rejected by a
grammar in which I use rule R3?

Thanks for any insights or comments.

Plenty:
[...]
int qux = bar(0)();

bar(0)() is an expression, not a declarator.

You are right -- I did not really look at it and my fingers coded
before I thought. Thanks for the correction; a _real_ example not
covered by (R3):
int (* (*a)(int))[5];

Actually, that is covered too. It is of the form
"(" declarator ")" "[" assignment-expression "]"
regardless of the fact that <declarator> contains more parentheses.

*g* I give up, I am too tired today...

Cheers
Michael