I would like to make a suggestion regarding the problem I posed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38443 (sorry I didn't check with the trunk).

To repeat it: the scope of a variable begins in its initializer instead of after it, making e.g. the following program output some random value instead of 1:

int main()
{
  int x = 0;
  { int x = x + 1;
    printf("%d\n", x);
  }
  return 0;
}

As I've learned from the reply this behaviour is not only an artifact of GCC, but it's mandated by the standard. Maybe it is correct in ISO C, but it's plain stupid. At least I cannot see any use for such behaviour, and I can see why it should be different.

I suggest to change the scoping rules so that variables become visible after their initializers, maybe leaving the old behaviour with -pedantic or -ansi.
There could also be a warning generated that it might not work with other compilers if somebody actually tries to use this feature.

Here are my reasons:

1) Consider the following code:
#define macro(a) \
{                \
   int x = (a);  \
/* ... some code ... */
}
void f()
{
   int x = 0;
   macro(x);
   /* ... */
}
And we get a very subtle bug here. Obviously, after getting a warning one could rename the variable, but it's just a vexation. And it's even more confusing if the code is auto-generated, or the macro is provided by some library header. One might remark here that I should use `_x' in the macro instead of `x'. OK, that's fine, but if you've got a macro inside a macro, then it gets more complicated. The truth is that with the current behaviour it's IMPOSSIBLE to ensure in advance that ANY macro works correctly without checking ALL its uses, and ALL variable names in ALL macros used by it, recursively.

2) The proposed scoping rules, besides being more coherent, are used in languages like ML or Lisp, so many people may assume them by default.

3) The proposed improvement may be non-conforming, but it cannot break any code, because anything which uses a variable in its own initializer is already broken.

4) This shouldn't be difficult to change, though I may be wrong here. I'm not familiar with GCC internals, but from what I know about compiler construction it should amount to moving a store to a symbol table (or whatever you have there) several statements forward.

5) Believe it or not, but it would make life easier for me. I'm used to write C code in a peculiar functional-like fashion, passing whole blocks to macros as if they were lambda-expression (possible with GCC). With this kind of style the issue comes up much more often.

This improvement is not very important, but its introduction would just make the language more coherent.

Forgive me if this issue was already discussed, or if you think it's not appropriate as a bug report (I rarely file bug reports for GCC, so I don't know what's appropriate ;)

Regards,
Łukasz Czajka