switch case question
Alessio
#include <stdio.h>
int main(void)
{
int i;
for ( i = 0; i < 10; i++ )
{
switch ( i )
{
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;
default:
printf("%d is NOT in case!\n", i);
break;
}
}
return 0;
}
What should be correct result ?
With lcc compilier I get that 3 and 4 are "NOT in case", with PelleC
compiler I get that only 6,7,8, and 9 are "NOT in case"...
Thank you,
Alessio.
jacob navia
With lcc-win I get:
0 is in case!
1 is in case!
2 is in case!
3 is NOT in case!
4 is NOT in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!
and that is the correct output.
Kenneth Brody
Only 0, 1, 2, and 5 are "in case". All other numbers are "NOT in case". If
PelleC says that 3 and 4 are "in case" given the exact code above, then it's
broken.
(I am assuming that your reference to lcc with 3 and 4 means that they, _in_
_addition_ _to_ 6, 7, 8, and 9, are "NOT in case", rather than _only_ 3 and 4.)
--
Kenneth Brody
Mark Bluemel
> Hi, please consider following code:
>
> #include <stdio.h>
>
> int main(void)
> {
> int i;
>
> for ( i = 0; i < 10; i++ )
> {
> switch ( i )
> {
> case 0:
> case 1:
> case 2:
> case 5:
> printf("%d is in case!\n", i);
> break;
>
> default:
> printf("%d is NOT in case!\n", i);
> break;
> }
> }
>
> return 0;
>
> }
>
> What should be correct result ?
What does your reading of the language specification and/or a good
reference suggest should be the correct result?
> With lcc compilier I get that 3 and 4 are "NOT in case",
Does "lcc" generate code that reports only 3 and 4 are "NOT in case"?
If so, then it's broken. However, I suspect you mean that with lcc you
get 3,4,6,7,8,9 are "NOT in case", which is correct.
> with PelleC compiler I get that only 6,7,8, and 9 are "NOT in case"...
Then PelleC seems to be generating incorrect code.
Note: it's often clearer to post your source, the output from a
compilation and the output from a run rather than a summary like this.
To illustrate, the example below shows that gcc works as I'd expect :-
$ cat alessio.c
#include <stdio.h>
int main(void) {
int i;
for ( i = 0; i < 10; i++ ) {
switch ( i ) {
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;
default:
printf("%d is NOT in case!\n", i);
break;
}
}
return 0;
}
$ cc -o alessio alessio.c
$ ./alessio
Alessio
> (I am assuming that your reference to lcc with 3 and 4 means that they,
> _in_ _addition_ _to_ 6, 7, 8, and 9, are "NOT in case", rather than
> _only_ 3 and 4.)
>
yes, you're right.
Alessio
gwowen
C:\Program Files\PellesC>type foo.c
#include <stdio.h>
int main(void)
{
int i;
for ( i = 0; i < 10; i++ )
{
switch ( i )
{
case 0:
case 1:
case 2:
case 5:
printf("%d is in case!\n", i);
break;
default:
printf("%d is NOT in case!\n", i);
break;
}
}
return 0;
}
C:\Program Files\PellesC>.\Bin\cc foo.c
foo.c
.\Bin\polink.exe foo.obj
C:\Program Files\PellesC>.\foo.exe
0 is in case!
1 is in case!
2 is in case!
3 is in case!
4 is in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!
-----------------------
YIKES!
Debanjan
Yes all others will be "in case" that's the correct output.
0 is in case!
1 is in case!
2 is in case!
3 is NOT in case!
4 is NOT in case!
5 is in case!
6 is NOT in case!
7 is NOT in case!
8 is NOT in case!
9 is NOT in case!
What else do you think ?
Morris Keesan
> Just to confirm the initial bug report...
>
> C:\Program Files\PellesC>type foo.c
<snip>
>
> C:\Program Files\PellesC>.\Bin\cc foo.c
> foo.c
> .\Bin\polink.exe foo.obj
>
> C:\Program Files\PellesC>.\foo.exe
<snip>
Two things strike me, here.
1) Do you really want to be putting your own source files in
C:\Program Files ???? This seems like a very strange practice.
2) I don't know anything about Pelles C, but if it were me,
before running the above test, I would do
del foo.*
to make sure there's no leftover foo.exe doing anything funny.
I find it hard to imagine a C compiler with any amount of
user base getting things wrong as badly as your output would
indicate. There's a wikipedia page for Pelles C, which says
that it's based on a modified version of lcc, and the initial
message says that lcc got it right.
--
Morris Keesan -- mke...@post.harvard.edu
Gareth Owen
> 1) Do you really want to be putting your own source files in
> C:\Program Files ???? This seems like a very strange practice.
Given that I only installed it for the test, and then deleted it
straight away, I think it'll be OK. I did it there so I didn't even
have to set the PATH, etc.
Normally no, I wouldn't do that. It's a bloody stupid thing to do.
> 2) I don't know anything about Pelles C, but if it were me,
> before running the above test, I would do
> del foo.*
> to make sure there's no leftover foo.exe doing anything funny.
Fresh install, see above.
> I find it hard to imagine a C compiler with any amount of
> user base getting things wrong as badly as your output would
> indicate.
Hence the "YIKES".
jacob navia
Look, compiler writing is a difficult business. Please post a
bug report to the author. Pelles C is based on lcc, and lcc
doesn't have this bug. Probably Pelles introduced this bug
later.
Alessio
> Look, compiler writing is a difficult business. Please post a
> bug report to the author.
Done.
Alessio
gwowen
> Pelles C is based on lcc...
> lcc doesn't have this bug...
> Probably Pelles introduced this bug later.
Probably?
Richard Bos
> "Morris Keesan" <mke...@post.harvard.edu> writes:
> > 2) I don't know anything about Pelles C, but if it were me,
> > before running the above test, I would do
> > del foo.*
> > to make sure there's no leftover foo.exe doing anything funny.
>
> Fresh install, see above.
>
> > I find it hard to imagine a C compiler with any amount of
> > user base getting things wrong as badly as your output would
> > indicate.
>
> Hence the "YIKES".
Odd. Must be a recent change. I have PellesC 2.90.8 installed here,
which is from 2004 or so, and it gives the correct output.
Richard