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
--
Summary: Suggestion: slight improvement of scoping rules
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lc235951 at students dot mimuw dot edu dot pl
GCC host triplet: irrelevant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38456
