Message-Id:	<199803230721.JAA25543@ankara.duzen.com.tr>
From:	"S. M. Halloran" <mitch AT duzen DOT com DOT tr>
Organization:	User RFC 822- and 1123-compliant
To:	djgpp AT delorie DOT com
Date:	Mon, 23 Mar 1998 09:25:41 +0200
MIME-Version:	1.0
Subject:	Re: "jump to case label" message; please help me!
In-reply-to:	<199803230553.VAA24539@adit.ap.net>

On 22 Mar 98 Nate Eldredge was found to have commented thusly:

> At 10:46  3/22/1998 -0600, Alex Weekley wrote:
> >Dan Chak wrote:
> >> 
> >> Scott Warner wrote:
> >> >
> >> > Dan Chak wrote:
> >> > >
> >> > > I have the following code in a program of mine which (to me) seems to be
> >> > > harmless.  However, I get an error with DJGPP that says "Error: Jump to
> >> > > case label" for the line that reads "case 3:".  Can anyone help me
> >> > > figure out why??
> [snipped]
> >The code posted by Dan is in fact perfect C. While it is fairly common
> >to put brackets in case statements like so...
> >
> >case 3:
> >{
> >	do_this();
> >	do_that();
> >	break;
> >}
> >
> >The brackets are completely unnecessary.
> >
> >A message "jump to case label" *should* mean that the program has a
> >block like...
> [snipped]
> >That code is entirely wrong and should generate a "jump to case label"
> >message. 
> 
> It's a somewhat more complex case than that. His code has a block-local
> variable declared inside a case. This is not legal C, since a variable
> declaration can occur only at the beginning of a block. Adding the brackets
> turns the statement executed in the appropriate case into a block, allowing
> it to have local variables.
> 
> A very simple example of the problem is this:
> 
> int f(int x)
> {
>   switch(x)
>     {
>       case 1:
>         int t; /* t is not declared at the start of the block. */
>         t = 2;
>         return t;
>       case 2:
>         return x;
>     }
>   return 0;
> }
> 
> However, this code gets the following reaction from GCC (2.7.2.1):
> 
> foon.c: In function `f':
> foon.c:6: parse error before `int'
> foon.c:7: `t' undeclared (first use this function)
> foon.c:7: (Each undeclared identifier is reported only once
> foon.c:7: for each function it appears in.)
> 
> Turbo C also barfs on it.
> 
> >My best guess is that its a problem with DJGPP. After all, a C/C++
> >compiler is an incredibly complex program, and you never know what kind
> >of subtle mistakes might show up in only very rare instances.
> 
> If this is a bug, it is simply that GCC (please don't say DJGPP) gives a
> misleading error message, not that it fails to compile correct code. You, or
> anyone else, is quite welcome to report that.
> 
> Nate Eldredge
> eldredge AT ap DOT net

When I originally looked at this code, I thought it was legal because I 
assumed the programmer was coding in C++ and not C, and since I am not 
conversant in all the esoterica of C++ and assumed that just about 
anything was legal in C++ for that matter, I figured the code was okay.  
After all, a programming language that lets you make your variable 
declarations/definitions in just about any place you want to put them 
should not probably find fault with the code as posted.

But I agree that if you are talking about C, the compiler should issue a 
diagnostic, although the one issued by gcc here is certainly confusing.  
In C the programmer should create a new (inner) block when making any 
variable declaration/definitions not at the scope of the function block.  
The programmer should note that the C compiler (gcc) will set up another 
stack frame for that block and once execution continues outside of the 
block, the stack frame will be lost and references to those variables will 
cause possibly run-time errors.

Why doesn't the programmer try this silly idea:  rename your source file 
such that is understood to be a C++ source, then run the compiler.  If it 
compiles okay, I somehow don't think I will be surprised.

Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara   TURKEY
mitch AT duzen DOT com DOT tr

other job title:  Sequoia's (dob 12-20-95) daddy

- Raw text -