This is the mail archive of the 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

> But there is nothing like "a lebel just like an ordinary automatic
> variable".  Once you introduce that notion, you start confusing
> people.  

There are no labels with block scope in C.  

But there are such labels in GNU C; that is the whole point of the
__label__ extension.  You and I don't have to like it, but it is what it
is. Fortunately, the fact that the user has to write "__label__" means
that anyone using this extension knows that it is an extension; at that
point, they know that the things they know about ISO C may not apply.
> | It would be very odd for it to work one way in statement-expressions,
> | but another way elsewhere 
> No, what is confusing is the notion os statement-expression.  
> don't act like anything else in the language.  Trying to have people
> believe that statement-expressions act like anything else in the
> language is creating promises and time-bomb confusion.
> It should be made clear that statement-expression don't behave like
> ordinary scopes. 

But they do act like ordinary scopes; that is a large portion of the
reason for their existence.  You can declare local variables in them,
for example, and variables with destructors declared in a
statement-expressions are destroyed before exiting the

The intended semantics of __label__ are quite clear.  The manual calls
them "local labels" because they are local to a scope.  The manual only
talks about using them in statement-expressions, but it does have
examples where they are used outside statement-expressions.  The C++
front end already implements the semantics I suggested, so doing as you
suggest would potentially break working code there.

Furthermore, the implementation of the semantics I suggest falls out
automatically. It is harder to special-case statement-expressions that
simply to do what I suggest.

I've got nothing more to say on this issue.

Mark Mitchell
CodeSourcery, LLC

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