472,127 Members | 1,631 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 472,127 software developers and data experts.

C99: variable declarations inside switch statements


Hello,

Unlike in pre-C99 versions of C where variables can only be defined at the
beginning of blocks, C99 allows variables to be defined in arbitrary
places inside blocks. However, gcc 3.2.2 seems to reveal that there
are still places where this is illegal. For instance, consider the
following code snippet.

int main(void) {
int i = 0;
switch (i) {
case 0:
char ch;
break;
}
}

Here the compiler complains with the error:

hello.c: In function `main':
hello.c:6: parse error before "char"

It seems like declaring a variable inside a switch statement is illegal.
Anyone know why this is the case. After all, the following compiles fine
with gcc 3.2.2:

int main(void) {
int i = 0;
switch (i) {
case 0: {
char ch;
break;
}
}
}

The only difference is the introduction of the block within the C
statement. Anyone know of similar cases where it is illegal to declare
variable in places where we would expect it to be legal in C99? Also,
can anyone explain the reason for the compiler complaint?

Thanks,

Neil

Nov 13 '05 #1
5 9918
On Mon, 27 Oct 2003 00:13:06 -0330, Neil Zanella wrote:
Unlike in pre-C99 versions of C where variables can only be defined at the
beginning of blocks, C99 allows variables to be defined in arbitrary
places inside blocks. However, gcc 3.2.2 seems to reveal that there
are still places where this is illegal. For instance, consider the
following code snippet.
You can't count on conformance of current versions of GCC
to the C99 standard. With that out of the way I'll continue.
int main(void) {
int i = 0;
switch (i) {
case 0:
char ch;
break;
}
}

Here the compiler complains with the error:

hello.c: In function `main':
hello.c:6: parse error before "char"

can anyone explain the reason for the compiler complaint?


The answer is in the C99 grammar. Declarations can appear at
any place within a block because of these productions:

A.2.3 Statements

(6.8.2) compound-statement: { block-item-list? }
(6.8.2) block-item-list: block-item
block-item-list block-item
(6.8.2) block-item: declaration
statement

But you can't put a declaration after a case construct because
of these productions:

A.2.3 Statements

(6.8) statement: labeled-statement
(6.8.1) labeled-statement: case constant-expression : statement

IOW, only a statement can follow a case.

-Sheldon
Nov 13 '05 #2
In article
<Pi*************************************@garfield. cs.mun.ca>,
Neil Zanella <nz******@cs.mun.ca> wrote:
Hello,

Unlike in pre-C99 versions of C where variables can only be defined at the
beginning of blocks, C99 allows variables to be defined in arbitrary
places inside blocks. However, gcc 3.2.2 seems to reveal that there
are still places where this is illegal. For instance, consider the
following code snippet.

int main(void) {
int i = 0;
switch (i) {
case 0:
char ch;
break;
}
}

Here the compiler complains with the error:

hello.c: In function `main':
hello.c:6: parse error before "char"

It seems like declaring a variable inside a switch statement is illegal.
Anyone know why this is the case. After all, the following compiles fine
with gcc 3.2.2:


No, declaring a variable inside a switch statement is not illegal.
However, the syntax is slightly different then you think it is: When you
write

switch (i) {
<body of switch statement>
}

the body of the switch statement can contain the following in any order:

Unlabeled statements
Labeled statements
Declarations

case 0: char ch;

would be a labeled declaration, and they are not allowed. Write

case 0: ;
char ch;
break;

instead.
Nov 13 '05 #3
Hello,

Quite interesting. I wonder whether adding a rule to the C99 grammar for
accepting declarations following labeled statements would cause the
resulting grammar to be ambiguous (I doubt it), or whether there
would be some shift/reduce, reduce/shift, reduce/reduce conflicts
of some sort (more likely). How would such conflicts arise in
such a situation?

Thanks,

Neil

Sheldon Simms <sh**********@yahoo.com> wrote:
The answer is in the C99 grammar. Declarations can appear at
any place within a block because of these productions:

A.2.3 Statements

(6.8.2) compound-statement: { block-item-list? }
(6.8.2) block-item-list: block-item
block-item-list block-item
(6.8.2) block-item: declaration
statement

But you can't put a declaration after a case construct because
of these productions:

A.2.3 Statements

(6.8) statement: labeled-statement
(6.8.1) labeled-statement: case constant-expression : statement

IOW, only a statement can follow a case.

-Sheldon

On Mon, 27 Oct 2003 00:13:06 -0330, Neil Zanella wrote:
int main(void) {
int i = 0;
switch (i) {
case 0:
char ch;
break;
}
}

Nov 13 '05 #4

top-posting corrected

On Tue, 28 Oct 2003 03:00:59 -0800, Neil Zanella wrote:

Sheldon Simms <sh**********@yahoo.com> wrote:
On Mon, 27 Oct 2003 00:13:06 -0330, Neil Zanella wrote:
> int main(void) {
> int i = 0;
> switch (i) {
> case 0:
> char ch;
> break;
> }
> }


The answer is in the C99 grammar. Declarations can appear at
any place within a block because of these productions:

A.2.3 Statements

(6.8.2) compound-statement: { block-item-list? }
(6.8.2) block-item-list: block-item
block-item-list block-item
(6.8.2) block-item: declaration
statement

But you can't put a declaration after a case construct because
of these productions:

A.2.3 Statements

(6.8) statement: labeled-statement
(6.8.1) labeled-statement: case constant-expression : statement

IOW, only a statement can follow a case.

-Sheldon

Quite interesting. I wonder whether adding a rule to the C99 grammar for
accepting declarations following labeled statements would cause the
resulting grammar to be ambiguous (I doubt it), or whether there
would be some shift/reduce, reduce/shift, reduce/reduce conflicts
of some sort (more likely). How would such conflicts arise in
such a situation?


I don't know if the C standards committee worries too much about
those kinds of problems when writing the grammar. I wouldn't in any
case. The grammer in the standard isn't supposed to be directly
usable in bison.

FWIW C++ *does* allow declarations after case and other labels with
these productions:

ISO/IEC 14882:1998(E)
A.5
statement: labeled-statement
declaration-statement

labeled-statement: case constant-expression : statement

declaration-statement : block-declaration

where block-declaration is the kind of declaration that can occur
inside a block (i.e. - no function definitions, template declaration,
etc.)

-Sheldon

Nov 13 '05 #5
In article <b6**************************@posting.google.com >,
nz******@cs.mun.ca (Neil Zanella) wrote:
Hello,

Quite interesting. I wonder whether adding a rule to the C99 grammar for
accepting declarations following labeled statements would cause the
resulting grammar to be ambiguous (I doubt it), or whether there
would be some shift/reduce, reduce/shift, reduce/reduce conflicts
of some sort (more likely). How would such conflicts arise in
such a situation?


Unlikely that this could introduce any conflicts.

We assume that there is no conflict between unlabeled statement and
declaration (otherwise C has a big problem anyway). Labels are quite
trivial to recognise and to distinguish from anything else. Once the
label is recognised, you are left again with the task of distinguishing
between unlabeled statement and declaration.
Nov 13 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

83 posts views Thread by Alexander Zatvornitskiy | last post: by
2 posts views Thread by Thomas Matthews | last post: by
134 posts views Thread by James A. Donald | last post: by
193 posts views Thread by Michael B. | last post: by
14 posts views Thread by subramanian100in | last post: by
80 posts views Thread by jacob navia | last post: by
reply views Thread by leo001 | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.