Question about variable scope conflict

[David Mathog]

I accidentally did this the other day (it was a lot less obvious in the
much longer actual program, hundreds of lines are omitted):

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int gbl_var=0; /* one of several globals */

void compare(void){
(void) fprintf(stdout, "gbl_var is %d\n",gbl_var);
}

int main(void){
int gbl_var; /* <----- OOPS, left over from a previous version */
gbl_var=1;
/* much code, including a qsort where the compare function
needed the value of gbl_var, but read 0 instead of 1.
Here just call compare directly */
compare();
exit(EXIT_SUCCE SS);
}
-----------------------------------------------------------
% gcc -Wall -std=c99 -pedantic -o foo foo.c
% #no warnings or errors are reported
% ./foo
gbl_var is 0
------------------------------------------------------------

Once I found the bug I was a bit surprised that the compiler had not
issued a warning. What does the standard say about using the same
variable name in two overlapping scopes like this? Apparently it allows
it, I guess to avoid accidental name conflicts, for instance between a
global in a library and a similarly named variable in a function.
Still, it would have been nice if the compiler could have at least
optionally warned about this. Unfortunately so far none of the -W
switches I've tried have flagged this problem, including
-Wredundant-decls. Is there a "-Wvar-nested-scope" that I missed.

Regards,

David Mathog

[santosh]

David Mathog wrote:

I accidentally did this the other day (it was a lot less obvious in
the much longer actual program, hundreds of lines are omitted):

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int gbl_var=0; /* one of several globals */

void compare(void){
(void) fprintf(stdout, "gbl_var is %d\n",gbl_var);
}

int main(void){
int gbl_var; /* <----- OOPS, left over from a previous version */
gbl_var=1;
/* much code, including a qsort where the compare function
needed the value of gbl_var, but read 0 instead of 1.
Here just call compare directly */
compare();
exit(EXIT_SUCCE SS);
}
-----------------------------------------------------------
% gcc -Wall -std=c99 -pedantic -o foo foo.c
% #no warnings or errors are reported
% ./foo
gbl_var is 0
------------------------------------------------------------

Once I found the bug I was a bit surprised that the compiler had not
issued a warning. What does the standard say about using the same
variable name in two overlapping scopes like this? Apparently it
allows it, I guess to avoid accidental name conflicts, for instance
between a global in a library and a similarly named variable in a
function. Still, it would have been nice if the compiler could have at
least
optionally warned about this.

Use the -Wshadow switch for gcc.

[santosh]

David Mathog wrote:

santosh wrote:

>Use the -Wshadow switch for gcc.

I never would have thought to call it that.

Any idea where the term "shadow variable" in this context originated?

It pretty common to informally say that an object in a particular
scope "shadows" an identically named object in an outer scope. So I
guess the name for that gcc diagnostics switch was taken from this.

<snip>

[Richard Heathfield]

David Mathog said:

I accidentally did this the other day (it was a lot less obvious in the
much longer actual program, hundreds of lines are omitted):

I'll trim a little more out for you:

int gbl_var=0; /* one of several globals */

void compare(void){
(void) fprintf(stdout, "gbl_var is %d\n",gbl_var);
}

int main(void){
int gbl_var; /* <----- OOPS, left over from a previous version */
gbl_var=1;

<snip>

Once I found the bug I was a bit surprised that the compiler had not
issued a warning. What does the standard say about using the same
variable name in two overlapping scopes like this?

It's perfectly legal, and the effect you noticed is conforming. The inner
scope's declaration takes precedence (if that's the right word!).

Apparently it allows
it, I guess to avoid accidental name conflicts, for instance between a
global in a library and a similarly named variable in a function.

Presumably, yes - but it's Yet Another Good Reason to minimise or even
eliminate your use of file scope objects.

Still, it would have been nice if the compiler could have at least
optionally warned about this.

You seem to be using gcc, so try the -Wshadow switch; here's what it does
with your code:

me@heregcc -Wshadow -o foo foo.c
foo.c: In function `main':
foo.c:11: warning: declaration of `gbl_var' shadows global declaration

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[dj3vande]

In article <KJ************ *********@bt.co m>,
Richard Heathfield <rj*@see.sig.in validwrote:

>David Mathog said:

>Apparently it allows
it, I guess to avoid accidental name conflicts, for instance between a
global in a library and a similarly named variable in a function.

Presumably, yes - but it's Yet Another Good Reason to minimise or even
eliminate your use of file scope objects.

I've found that putting all of the file scope objects in one of two
structs (one for external linkage and one for internal) both makes it
harder to run into this problem and makes keeping track of what's where
a lot easier.
(So instead of having num_fds at file scope and curr_fd at function
scope, I have ioloop_data.num _fds at file scope and when I see curr_fd
in the code I know it's _not_ at file scope.)

This also has the side effect of making it a lot easier to eliminate
file-scope variables entirely should it be necessary to do so (they're
already wrapped up nicely in a struct, and all that's required is
adding code to create and destroy copies of that struct and changing
the existing interfaces to include a pointer to that struct everywhere
- not always trivial, but not nearly as hard as it could be). I've had
to do that rather less often than I've written code that used a single
struct to hold its file-scope objects, but even looking at just that
side effect the cost-benefit ratio probably comes out favoring the
benefit side.
dave

[CBFalconer]

David Mathog wrote:

santosh wrote:

>Use the -Wshadow switch for gcc.

I never would have thought to call it that.

Any idea where the term "shadow variable" in this context originated?

No. However, you may not want to use that, since one use of local
names is to deliberately prevent accidental use of the external
scopes object within the local scope. I.e. a local definition of
foo prevents accessing any external (scope) foo.

--
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home .att.net>
Try the download section.

--
Posted via a free Usenet account from http://www.teranews.com

[Dave Hansen]

On Nov 30, 11:20 am, David Mathog <mat...@caltech .eduwrote:

I accidentally did this the other day (it was a lot less obvious in the
much longer actual program, hundreds of lines are omitted):

[...]

>
Once I found the bug I was a bit surprised that the compiler had not
issued a warning. What does the standard say about using the same

Lint early. Lint often. Lint is your friend. www.gimpel.com

(No connection to Gimpel, just a satisfied customer).

Regards,

-=Dave

[Barry Schwarz]

On Fri, 30 Nov 2007 09:20:21 -0800, David Mathog <ma****@caltech .edu>
wrote:

>I accidentally did this the other day (it was a lot less obvious in the
much longer actual program, hundreds of lines are omitted):

----------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>

int gbl_var=0; /* one of several globals */

void compare(void){
(void) fprintf(stdout, "gbl_var is %d\n",gbl_var);
}

int main(void){
int gbl_var; /* <----- OOPS, left over from a previous version */
gbl_var=1;
/* much code, including a qsort where the compare function
needed the value of gbl_var, but read 0 instead of 1.
Here just call compare directly */
compare();
exit(EXIT_SUCCE SS);
}
-----------------------------------------------------------
% gcc -Wall -std=c99 -pedantic -o foo foo.c
% #no warnings or errors are reported
% ./foo
gbl_var is 0
------------------------------------------------------------

Once I found the bug I was a bit surprised that the compiler had not
issued a warning. What does the standard say about using the same

There is no error so no diagnostic is required. Some compilers will
produce a warning, basically a "did you really mean to do this" type
of reminder.

>variable name in two overlapping scopes like this? Apparently it allows

The variable defined inside the function basically hides the variable
at file scope for any statements in the function.

>it, I guess to avoid accidental name conflicts, for instance between a
global in a library and a similarly named variable in a function.
Still, it would have been nice if the compiler could have at least
optionally warned about this. Unfortunately so far none of the -W
switches I've tried have flagged this problem, including
-Wredundant-decls. Is there a "-Wvar-nested-scope" that I missed.

Questions about a specific compiler are better asked in a newsgroup
that discusses it.
Remove del for email