Scopes in which __label__ can appear

[Zack Weinberg]

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.  (I am, as I said, content to disallow
use of __label__ outside the documented contexts for it.)

zw