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:

> 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.

Use the -Wshadow switch for gcc.

Re: Question about variable scope conflict
 

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?
Only two threads using that term have previously appeared in this group,
and only two in comp.lang.c++. A bit of googling on the web at large
turned up what appear to be different usages of the term for VoiceXML
automake, and several others. In most of these it means not overlapping
declarations, but using two variables with slightly different names, and
often different types, which are operated on similarly in most of the
code. Here is a typical use, ironically again with respect to gcc:

http://developer.apple.com/documenta...eMismatch.html

Thanks,

David Mathog

Re: Question about variable scope conflict
 

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>

Re: Question about variable scope conflict
 

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@here> gcc -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.invalid> wrote:
>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

Re: Question about variable scope conflict
 

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

Re: Question about variable scope conflict
 

On Nov 30, 11:20 am, David Mathog <mat...@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):
[...]
>
> 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

Re: Question about variable scope conflict
 

On Fri, 30 Nov 2007 09:20:21 -0800, David Mathog <mathog@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_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

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

Re: Question about variable scope conflict
 

On Nov 30, 10:05 am, David Mathog <mat...@caltech.edu> 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?

This is probably ancient computer science. When two entities are
indexed under the same search key (address, name, ID, ...), and the
situation is resolved by simply favoring one and hiding the other,
this is called shadowing.

Shadow ROM, shadow registers, etc.

Shadow ROM: memory which appears at some address range at machine
reset, but can be turned off, revealing RAM ``underneath'' (possibly
with writes being allowed ``through'' to the RAM at all times).

The term is used in the Common Lisp programming language, and is
defined in the glossary of the its ANSI standard:

http://www.lisp.org/HyperSpec/Body/glo_s.html#shadow

> Only two threads using that term have previously appeared in this group,

What? Searching for the term shadowing in comp.lang.c reveals tons of
hits, going way back.

> and only two in comp.lang.c++. A bit of googling on the web at large
> turned up what appear to be different usages of the term for VoiceXML
> automake, and several others.

> In most of these it means not overlapping
> declarations, but using two variables with slightly different names, and
> often different types, which are operated on similarly in most of the
> code.

That's a silly misuse of shadowing. If the names are different, it's
simply not shadowing. What this is describing is redundant code, cut-
and-paste coding, ``whitebox reuse'' or something along those lines.

In the case of Makefile variables, you have to be careful. Makefiles
often manipulate variables whose names are the result of string
processing. So for instance FOO_CFLAGS and DEFAULT_CFLAGS might
actually be considered to be the same name in different namespaces
(under the special rules of a given Makefile design). It could be the
case that for instance FOO_CFLAGS means the CFLAGS to use for
compiling the targets of project FOO, which, if available, shadow the
DEFAULT_CFLAGS that would otherwise be used.

> http://developer.apple.com/documenta...eMismatch.html

In this situation, two variables are used to represent the same value
(in a different way), and are kept synchronized to avoid conversion
between the two represenations. The word the author is looking for is
``alias''.

shadow: single reference, multiple items.
alias: multiple references, same item.