Switch() parsing insanity

[Robert]

#include <stdio.h>

int main() {
switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");
};
return 0;
}

When I try to compile the above code with gcc 3.3.4 on linux, I get the
following error:

bug.c: In function `main':
bug.c:6: error: parse error before "int"

Placing a statement such as printf, or even just a plain empty statement
(";") before "int msglen = 22;" makes it compile and work fine. Is
there some rule forbidding declaring variables directly after case
statements, or could it possibly be a bug with gcc? I'm not too keen to
try updating gcc since compiling kernels is apparently very touchy with
compiler versions.

Thanks in advance,
Robert

 

[S.Tobias]

[snipped at places]

switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");

bug.c: In function `main':
bug.c:6: error: parse error before "int"

Placing a statement such as printf, or even just a plain empty statement
(";") before "int msglen = 22;" makes it compile and work fine. Is
there some rule forbidding declaring variables directly after case
statements, or could it possibly be a bug with gcc? I'm not too keen to

Syntax for labeles. Gcc is right.

Google clc for:
Subject: C99 mixed declarations / switch case / weird syntax behavior
Message-ID: <[email protected]>

 

[Eric Sosman]

#include <stdio.h>

int main() {
switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");
};
return 0;
}

When I try to compile the above code with gcc 3.3.4 on linux, I get the
following error:

bug.c: In function `main':
bug.c:6: error: parse error before "int"

Placing a statement such as printf, or even just a plain empty statement
(";") before "int msglen = 22;" makes it compile and work fine. Is
there some rule forbidding declaring variables directly after case
statements, or could it possibly be a bug with gcc? I'm not too keen to
try updating gcc since compiling kernels is apparently very touchy with
compiler versions.

Labels precede statements; `int msglen = 22;' is not a
statement but a declaration. One way to solve your immediate
problem is to attach the label to a null statement

case 29: ;
int msglen = 22;
...

 

[CBFalconer]

[snipped at places]

switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");

bug.c: In function `main':
bug.c:6: error: parse error before "int"

Placing a statement such as printf, or even just a plain empty
statement (";") before "int msglen = 22;" makes it compile and
work fine. Is there some rule forbidding declaring variables
directly after case statements, or could it possibly be a bug
with gcc? I'm not too keen to

Syntax for labeles. Gcc is right.

.... snip ...

From N869. Note the very last line.

6.2.1 Scopes of identifiers

.... snip ...

[#3] A label name is the only kind of identifier that has
function scope. It can be used (in a goto statement)
anywhere in the function in which it appears, and is
declared implicitly by its syntactic appearance (followed by
a : and a statement). *

 

[Chris Hulbert]

6.2.1 Scopes of identifiers

... snip ...

[#3] A label name is the only kind of identifier that has
function scope. It can be used (in a goto statement)
anywhere in the function in which it appears, and is
declared implicitly by its syntactic appearance (followed by
a : and a statement). *

What about the following? This is what I generally do when I use
variables with that scope.

switch ( 29 )
{
case 29:
{
int msglen = 22;
printf("Hello\n");
}
}

 

[Eric Sosman]

6.2.1 Scopes of identifiers

... snip ...

[#3] A label name is the only kind of identifier that has
function scope. It can be used (in a goto statement)
anywhere in the function in which it appears, and is
declared implicitly by its syntactic appearance (followed by
a : and a statement). *

What about the following? This is what I generally do when I use
variables with that scope.

switch ( 29 )
{
case 29:
{
int msglen = 22;
printf("Hello\n");
}
}

That's fine: a brace-enclosed { block } is a compound
statement, which is a statement, so it can be labelled.
Prior to C99, this was the only way to declare new variables
"in medias res."

 

[S.Tobias]

[snipped at places]

switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");

bug.c: In function `main':
bug.c:6: error: parse error before "int"

[snip]

Syntax for labeles. Gcc is right.

... snip ...

From N869. Note the very last line.

6.2.1 Scopes of identifiers

[snip]

Yeah, right, my sloppy writing. I should've said "Syntax for
labeled-statements". But "case ??:" and "default:" things
are called labels, too.

 

[SM Ryan]

# #include <stdio.h>
#
# int main() {
# switch (29) {
# case 29:
# int msglen = 22;
# printf("Hello\n");
# };
# return 0;
# }
#
# When I try to compile the above code with gcc 3.3.4 on linux, I get the
# following error:
#
# bug.c: In function `main':
# bug.c:6: error: parse error before "int"

It's not a good idea to put declarations after any labels. If you want
msglen available in other switch branches, you can declare it above the
switch. If you only want to use it in this branch, make the branch a
block
switch (29) {
case 29: {
int msglen = 22;
printf("Hello\n");
}
}

If you want the compiler to recognise switch(29) case 29: is a no-op,
you're expecting too much.

 

[Emmanuel Delahaye]

Robert wrote on 21/07/05 :

#include <stdio.h>

int main() {
switch (29) {
case 29:
int msglen = 22;
printf("Hello\n");
};
return 0;
}

When I try to compile the above code with gcc 3.3.4 on linux, I get the
following error:

bug.c: In function `main':
bug.c:6: error: parse error before "int"

This is fine:

#include <stdio.h>

int main (void)
{
switch (29)
{
case 29:
{
int msglen = 22;
printf ("Hello\n");
}
}
return 0;
}

In C90, you need a block to define a local.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

I once asked an expert COBOL programmer, how to
declare local variables in COBOL, the reply was:
"what is a local variable?"

 

[Robert]

If you want the compiler to recognise switch(29) case 29: is a no-op,

you're expecting too much.

Haha, no. This was just my boiled-down code from the original 700 lines
exhibiting the bug.

Thanks all for the spot-on replies.

-- Robert