This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]