Strange behaviour with switch-case
dragoncoder
int main()
{
int sw = 22;
switch(sw) {
case 1:
case 2:
case 3:
fprintf(stderr, "this is a %d\n", sw);
break;
xxxxx:
fprintf(stderr, "this is something else\n");
break;
}
return 0;
}
I suspected this code not to compile but it does compile and nothing
is printed. If I add a default section inside, that is executed.
My question is why does the compiler allow this code to be compiled
and what is the significance of xxxxx: section in this code? Is there
any use of this?
Many thanks
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
Seebs
> My question is why does the compiler allow this code to be compiled
> and what is the significance of xxxxx: section in this code? Is there
> any use of this?
It's a label, like for a goto. e.g.:
xxxx:
...
goto xxxx;
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Keith Thompson
> #include <stdio.h>
>
> int main()
> {
> int sw = 22;
>
> switch(sw) {
> case 1:
> case 2:
> case 3:
> fprintf(stderr, "this is a %d\n", sw);
> break;
> xxxxx:
> fprintf(stderr, "this is something else\n");
> break;
> }
> return 0;
> }
The "xxxxx:" is a label. It's not a switch label like "case 1:",
it's a label that could be the target of a goto.
A goto label can appear in front of any statement. This one happens
to appear inside a switch statement, which is legal but confusing.
Note that you could have written "defau1t:" or "Default:" with the
same effect.
The code is deliberately obfuscated.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
news
> #include <stdio.h>
>
> int main()
> {
> int sw = 22;
>
> switch(sw) {
> case 1:
> case 2:
> case 3:
> fprintf(stderr, "this is a %d\n", sw);
> break;
> xxxxx:
> fprintf(stderr, "this is something else\n");
> break;
> }
> return 0;
> }
>
> I suspected this code not to compile but it does compile and nothing
> is printed. If I add a default section inside, that is executed.
>
> My question is why does the compiler allow this code to be compiled
> and what is the significance of xxxxx: section in this code? Is there
> any use of this?
I tried it with gcc4 and it just compiled, and printed nothing.
I think xxxxx: is understood as label which you could use goto to jump.
At least it looks like it.
--
Never reveal your best argument.
Francis Glassborow
> #include <stdio.h>
>
> int main()
> {
> int sw = 22;
>
> switch(sw) {
> case 1:
> case 2:
> case 3:
> fprintf(stderr, "this is a %d\n", sw);
> break;
> xxxxx:
> fprintf(stderr, "this is something else\n");
> break;
> }
> return 0;
> }
>
> I suspected this code not to compile but it does compile and nothing
> is printed. If I add a default section inside, that is executed.
>
> My question is why does the compiler allow this code to be compiled
> and what is the significance of xxxxx: section in this code? Is there
> any use of this?
Because xxxxx is a perfectly valid label (as a destination for a goto).
Using it via a goto might have all kinds of dire results but as it
stands the compiler has no reason to object to it.
This is an example of something that is often the result of a typing
error. If you omit the space after case, for example type 'case1' when
you meant to type 'case 1' the code is syntactically correct but will
not do what you expected.
Tinkertim
> 5.11.2009 22:38, dragoncoder kirjoitti:
>
>
>
>
>
> > #include <stdio.h>
>
> > int main()
> > {
> > int sw = 22;
>
> > switch(sw) {
> > case 1:
> > case 2:
> > case 3:
> > fprintf(stderr, "this is a %d\n", sw);
> > break;
> > xxxxx:
> > fprintf(stderr, "this is something else\n");
> > break;
> > }
> > return 0;
> > }
>
> > I suspected this code not to compile but it does compile and nothing
> > is printed. If I add a default section inside, that is executed.
>
> > My question is why does the compiler allow this code to be compiled
> > and what is the significance of xxxxx: section in this code? Is there
> > any use of this?
>
> I tried it with gcc4 and it just compiled, and printed nothing.
>
> I think xxxxx: is understood as label which you could use goto to jump.
> At least it looks like it.
There is a switch to tell gcc to speak up if you define a label that
is not used. I just can't think of it off of the top of my head.
I inherited code very similar to the OP's, but 2500 lines long. It was
the most convoluted switch-case-goto mess I'd ever seen.
The particular switch turns on very few other warnings. I just
searched through the documentation for the latest version and can't
find it.
Hans-Bernhard Bröker
> There is a switch to tell gcc to speak up if you define a label that
> is not used. I just can't think of it off of the top of my head.
That switch, BTW, is -Wunused-label. Kind-a obvious, isn't it? ;->
> The particular switch turns on very few other warnings. I just
> searched through the documentation for the latest version and can't
> find it.
$ info gcc invoking warning
then ^S "label" ^S ^S
With those things pointed out, the truth of course remains that
compilers (even ones as tunable as GCC) are ultimately the wrong tool
for that job. Lint early, lint often. A decent lint will find this and
lots of other likely typos/thinkos faster than you can open your C
textbook, much less ask questions in a newsgroup.
Philip Paeps
> Tinkertim wrote:
> > There is a switch to tell gcc to speak up if you define a label that
> > is not used. I just can't think of it off of the top of my head.
>
> That switch, BTW, is -Wunused-label. Kind-a obvious, isn't it? ;->
>
> > The particular switch turns on very few other warnings. I just
> > searched through the documentation for the latest version and can't
> > find it.
>
> $ info gcc invoking warning
>
> then ^S "label" ^S ^S
>
> With those things pointed out, the truth of course remains that compilers
> (even ones as tunable as GCC) are ultimately the wrong tool for that job.
> Lint early, lint often. A decent lint will find this and lots of other
> likely typos/thinkos faster than you can open your C textbook, much less ask
> questions in a newsgroup.
FlexeLint is your friend? :-)
- Philip [also addicted]
--
Philip Paeps Please don't email any replies
phi...@paeps.cx I follow the newsgroup.
Of two possible events,
only the undesired one will occur.
Keith Thompson
[...]
> With those things pointed out, the truth of course remains that
> compilers (even ones as tunable as GCC) are ultimately the wrong tool
> for that job. Lint early, lint often. A decent lint will find this
> and lots of other likely typos/thinkos faster than you can open your C
> textbook, much less ask questions in a newsgroup.
I think C is fairly unusual in the way that compilation and thorough
code checking are commonly separated into two different tools. In
other languages I've worked with, there is no separate lint-like tool;
rather the compiler can be configured to do stronger checking.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Hans-Bernhard Bröker
> I think C is fairly unusual in the way that compilation and thorough
> code checking are commonly separated into two different tools.
For some reason FORTRAN 77 springs to mind as another example.
> In other languages I've worked with, there is no separate lint-like
> tool; rather the compiler can be configured to do stronger checking.
That might be somewhat related to there being such a thing as "the"
compiler for some of those languages --- for C there are terribly many,
and it would be quite wasteful to duplicate the entire thorough code
checking engine in each of them.
It's basically the original Unix tool philosophy at work: one tool <-->
one task.
Keith Thompson
> Keith Thompson wrote:
>> I think C is fairly unusual in the way that compilation and thorough
>> code checking are commonly separated into two different tools.
>
> For some reason FORTRAN 77 springs to mind as another example.
I'll take your word for that.
>> In other languages I've worked with, there is no separate lint-like
>> tool; rather the compiler can be configured to do stronger checking.
>
> That might be somewhat related to there being such a thing as "the"
> compiler for some of those languages --- for C there are terribly
> many, and it would be quite wasteful to duplicate the entire thorough
> code checking engine in each of them.
>
> It's basically the original Unix tool philosophy at work: one tool
> <-->
> one task.
Ah, but didn't the compiler/lint distinction originate before there
multiple C compilers became available?
I thought that lint originally shared substantial code with the
compiler, and was made a separate tool at least partly because
of memory constraints (you can have strong checking, or you can
generate code; choose one).
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Francis Glassborow
> Hans-Bernhard Bröker <HBBr...@t-online.de> writes:
>> Keith Thompson wrote:
>>> I think C is fairly unusual in the way that compilation and thorough
>>> code checking are commonly separated into two different tools.
>> For some reason FORTRAN 77 springs to mind as another example.
>
> I'll take your word for that.
>
>>> In other languages I've worked with, there is no separate lint-like
>>> tool; rather the compiler can be configured to do stronger checking.
>> That might be somewhat related to there being such a thing as "the"
>> compiler for some of those languages --- for C there are terribly
>> many, and it would be quite wasteful to duplicate the entire thorough
>> code checking engine in each of them.
>>
>> It's basically the original Unix tool philosophy at work: one tool
>> <-->
>> one task.
>
> Ah, but didn't the compiler/lint distinction originate before there
> multiple C compilers became available?
>
> I thought that lint originally shared substantial code with the
> compiler, and was made a separate tool at least partly because
> of memory constraints (you can have strong checking, or you can
> generate code; choose one).
>
Actually my impression was that lint was a tool created to address
problems that arose because of separate compilation.
Al Muliman
> #include <stdio.h>
>
> int main()
> {
> int sw = 22;
>
> switch(sw) {
> case 1:
> case 2:
> case 3:
> fprintf(stderr, "this is a %d\n", sw);
> break;
> xxxxx:
> fprintf(stderr, "this is something else\n");
> break;
> }
> return 0;
> }
>
> I suspected this code not to compile but it does compile and nothing
> is printed. If I add a default section inside, that is executed.
>
> My question is why does the compiler allow this code to be compiled
> and what is the significance of xxxxx: section in this code? Is there
> any use of this?
Is anyone else reminded of Duff's device?
http://en.wikipedia.org/wiki/Duff's_device
__
Al