Topic: Illegal jump past initializer redux


Author: neeri@iis.ee.ethz.ch (Matthias Neeracher)
Date: 1995/07/19
Raw View
[I have cross-posted this to comp.stdc++ to solicit responses from C++ Standard
experts]

In article <johnmce-1807951205060001@10.0.2.15>, johnmce@world.std.com (John McEnerney) writes:
> In article <chopps-1807951113440001@wine.emich.edu>,
> chopps@water.emich.edu (Christian E. Hopps) wrote:

>> A::A()
>> {
>> extern int error;
>> if (error)
>> return;
>> B b;
>> }  <-- Error   : illegal jump past initializer

> I can see why the compiler thinks it is a bug. To the compiler it looks
> just like:

>     if (error) goto L1;
>     B b;
> L1: return;

> The ARM states "it is illegal to jump past a declaration with an explicit
> or implicit initializer unless the declaration is in an inner block that
> is not entered..."

The Committee Draft (28 April 1995) formulates this issue a little clearer as
"A program that jumps from a point where a local variable with automatic
storage duration is not in scope to a point where it is in scope is ill-formed
[...]" [6.7]

The question, thus, is whether your interpretation of "return" is allowed.
The standard writes that
"A function returns to its caller by the return statement" [6.6.3]

To me, this language implies clearly that "return" transfers control *out* of a
scope, i.e. that

void b()
{  A x;
   return;
   B y;
}

void a()
{  b();
}

is (in this context) equivalent to

void a()
{
   {   A x;
       goto L1;
       B y;
   }
L1: ;
}

and not to:

void a()
{
   {   A x;
       goto L1;
       B y;
L1: ;
   }
}

and the former, as opposed to the latter, is legal. I don't think that the
Draft Standard supports your assumption that local variables of a procedure are
in scope at the destination of a return.

Matthias

-----
Matthias Neeracher <neeri@iis.ee.ethz.ch> http://err.ethz.ch/members/neeri.html
  "Paranotions, which designate constructs, may now contain metanotions and
   ``hypernotions'' have been introduced in order to designate protonotions"
                -- A. van Wijngaarden et al., _ALGOL 68 Revised Report_