Question about variable scope conflict

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_SUCCESS);
}
-----------------------------------------------------------
% 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

re: Question about variable scope conflict

David Mathog wrote:
Use the -Wshadow switch for gcc.

re: Question about variable scope conflict

David Mathog wrote:
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>

re: Question about variable scope conflict

David Mathog said:
I'll trim a little more out for you:
<snip>
It's perfectly legal, and the effect you noticed is conforming. The inner
scope's declaration takes precedence (if that's the right word!).
Presumably, yes - but it's Yet Another Good Reason to minimise or even
eliminate your use of file scope objects.
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

re: Question about variable scope conflict

In article <KJ6dnaWOWI16xc3aRVnyuQA@bt.com>,
Richard Heathfield <rjh@see.sig.invalidwrote: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

re: Question about variable scope conflict

David Mathog wrote: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

re: Question about variable scope conflict

On Nov 30, 11:20 am, David Mathog <mat...@caltech.eduwrote:[...]Lint early. Lint often. Lint is your friend. www.gimpel.com

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

Regards,

-=Dave

re: Question about variable scope conflict

On Fri, 30 Nov 2007 09:20:21 -0800, David Mathog <mathog@caltech.edu>
wrote:
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.
The variable defined inside the function basically hides the variable
at file scope for any statements in the function.
Questions about a specific compiler are better asked in a newsgroup
that discusses it.


Remove del for email