Scopes in which __label__ can appear

[Zack Weinberg]

Consider the following code (from c-torture/execute/920428-2.c):

int s (int i)
{
  if (i > 0)
    {
      __label__ l1;
      int f (int i)
      {
        if (i == 2)
          goto l1;
        return 0;
      }
      return f (i);
    l1:;
    }
  return 1;
}

The present compiler interprets this as functionally equivalent to

int s (int i)
{
  __label__ l1;
  int f (int i)
  {
    if (i == 2)
      goto l1;
    return 0;
  }

  if (i > 0)
    {
      return f (i);
    l1:;
    }
  return 1;
}

However, the documentation strongly implies that it is ill-formed.
Furthermore, this code

int s(int i)
{
  if (i > 0)
  {
    __label__ l1;

    if (i == 1) goto l1;
    return 0;

  l1:
    return 1;
  }

  if (i == 0) goto l1;
  return 2;

 l1:
  return 3;
}

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.

Since the documentation currently implies that __label__ can only
appear at the outermost scope of a function (including nested
functions) or of a statement expression, my first choice is to make it
ill-formed.  This would necessitate a change to 920428-2.c along the
lines of the transformation shown above.  I am pretty sure that that
would not change what that testcase is testing, but I was not around
in 1992 so I don't know what the history is.

I am also willing to make __label__ at nested block scope well-formed,
but only if the second example becomes well-formed too.

(It seems silly to me to allow nested functions at nested block scope,
but forbidding them is beyond my threshold of pain at the moment.)

zw