This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Scopes in which __label__ can appear
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