switch case question

[Alessio]

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 ?
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]

Alessio a écrit :

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 ?
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"...

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.

 

[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
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!

 

[Alessio]

Kenneth Brody ha scritto:

(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]

Just to confirm the initial bug report...

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!

 

[Morris Keesan]

Just to confirm the initial bug report...

C:\Program Files\PellesC>type foo.c

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.

 

[jacob navia]

Gareth Owen a écrit :

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.


Fresh install, see above.


Hence the "YIKES".

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]

jacob navia ha scritto:

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]

Fresh install, see above.


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