This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Scopes in which __label__ can appear
On Sat, 2003-07-19 at 12:52, Zack Weinberg wrote:
> Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
>
> > | > In parallel to your argument, there is no particular reason to reject
> > | > the above.
> > |
> > | So the __label__ in this example has no effect at all?
> >
> > Basically, I'm saying yes. It would be a no-op.
>
> I don't like that, I think it'd be confusing and surprising to users.
> I'd much rather either reject the code or narrow the scope of the
> label (and therefore reject the code because the label isn't in scope
> for the goto).
>
> Also, from an implementation point of view, either of my preferred
> options is cleaner than what you are suggesting.
I agree with Zack.
__label__ should have two effects:
#1: It makes the label accessible to a nested function.
#2: It declares a label with block-scope, as opposed to the ordinary C
function-scope label. That is the effect that makes __label__ useful in
statement-expressions.
In other words, this code:
void f() { { __label__ l; l: ; } goto l; }
should be invalid.
The idea is that a label declared with "__label__" is just like an
ordinary automatic variable; it "goes out of scope" at the closing curly
brace of its enclosing block.
It would be very odd for it to work one way in statement-expressions,
but another way elsewhere -- you should be able to move code in and out
of statement-expressions at will. A way to say that more formally is
that the expression-statement:
({ /* Code here */ });
should be equivalent to the compound-statement:
{ /* Code here */ }
Now, in my ideal world, statement-expressions and __label__ would not
exist. In my slightly-less-ideal world, __label__ would not have two
semantic implications, but only one. But, for now, neither of these
options is on the table.
--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com