Scopes in which __label__ can appear

[Gabriel Dos Reis]

"Zack Weinberg" <zack@codesourcery.com> writes:

| Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
| 
| > "Zack Weinberg" <zack@codesourcery.com> writes:
| >
| > [...]
| >
| > | should either be ill-formed on the grounds that __label__ cannot
| > | appear at nested block scope other than a statement expression or
| > | nested function, or it should be well-formed and equivalent to
| > | 
| > | int s(int i)
| > | {
| > |   if (i > 1)  return 0;
| > |   if (i == 1) return 1;
| > |   if (i < 0)  return 2;
| > |   /* if (i == 0) */ return 3;
| > | }
| > | 
| > | but what the present compiler does is reject it on the grounds that l1
| > | has been defined twice.  In other words, the effect of __label__ at
| > | nested block scope (other than a statement expression or nested
| > | function) is as if the __label__ appeared at function scope.  I think
| > | this violates least surprise and should be changed.
| >
| > On the contrary, I think is consistent with the scope of label as
| > defined by both C and C++ standards.  
| > Remember labels have function-scope.  Suddenly changing labels
| > (explicitly declared -- GNU extension I concede) to have a
| > local-scope will violates the "least surprise" principle. 
| 
| Does your opinion change if I point out that the documented effect of
| __label__ has always been to give the label a local scope?  It happens
| only to work in the context of statement expressions, but the
| documentation doesn't say that.

if it does not work in the context of statement expressions, what
usefulness would it have?  (This is a real question, not  a rhetorical
one). 

|  (I am, as I said, content to disallow
| use of __label__ outside the documented contexts for it.)