[Bug c/38456] New: Suggestion: slight improvement of scoping rules

[Bug c/38456] New: Suggestion: slight improvement of scoping rules

[lc235951 at students dot mimuw dot edu dot pl]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3337 bytes --]

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

[Bug c/38456] Suggestion: slight improvement of scoping rules

[brian at dessent dot net]

------- Comment #1 from brian at dessent dot net  2008-12-09 18:53 -------
Subject: Re:   New: Suggestion: slight improvement of scoping rules

I seriously don't think you will ever convince anyone to change a facet
of gcc which is currently following the standard to something that is
non-standard.

Besides, you can solve the unique name problem like this:

#define UNIQUIFY2(a,b) a##b
#define UNIQUIFY1(a,b) UNIQUIFY2(a,b)
#define UNIQUIFY(x) UNIQUIFY1(x_,__COUNTER__)

#define macro(a) \
({               \
   __typeof(a) UNIQUIFY(a) = (a);  \
/* ... some code ... */ \
})

__COUNTER__ was new in 4.3.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38456

[Bug c/38456] Suggestion: slight improvement of scoping rules

[steven at gcc dot gnu dot org]

------- Comment #2 from steven at gcc dot gnu dot org  2008-12-09 18:59 -------
This is what -Wshadow is for.  We can't invent a new C dialect or "fix" the
standard.


-- 

steven at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38456

[Bug c/38456] Suggestion: slight improvement of scoping rules

[lc235951 at students dot mimuw dot edu dot pl]

------- Comment #3 from lc235951 at students dot mimuw dot edu dot pl  2008-12-09 19:09 -------
I know I can turn on warnings or use some tricks like UNIQUIFY(), but it's just
cumbersome with large macros.

I also know that changing the standard is considered "not done", but in this
case it cannot have any undesirable consequences, because any code exploiting
this behaviour is by definition incorrect (except for the case that you want to
get a random value from the stack in a really strange way). The only drawback
is that users may get used to it and try it with other compilers, so I proposed
a warning.

Well, but if you insist on such strict compliance then let it be so. After all
it's not that very important.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38456