The term "global variables" misleading?

[j]

Anyone here feel that "global variables" is misleading for variables
whose scope is file scope? "global" seems to imply global visibility,
while this isn't true for variables whose scope is file scope. If you
have a variable whose scope is file scope in another translation unit,
you have to provide a local declaration to access that variable from
the other translation unit.

Also, I don't see "global variable" used once in the standard. So
would it be more correct to refer to such variables that are often
referred to with the term "global variable" as just variables whose
scope is file scope?

 

[j]

On 25 Jul 2003 09:49:32 -0700
(e-mail address removed) (j) wrote:



They're called static or non-automatic. Reread your C book.

static? Standard certainly doesn't name them as such unless they are
explicitly declared with the static storage class specifier. I would
choose what the standard states over any book, anyday..

I was just looking for what people thought on the use of "global
variable" period, and if they thought it was a misleading term in
describing a variable whose scope is file scope and where the storage
is external..

 

[Larry__Weiss]

Anyone here feel that "global variables" is misleading for variables
whose scope is file scope? "global" seems to imply global visibility,
while this isn't true for variables whose scope is file scope. If you
have a variable whose scope is file scope in another translation unit,
you have to provide a local declaration to access that variable from
the other translation unit.

Also, I don't see "global variable" used once in the standard. So
would it be more correct to refer to such variables that are often
referred to with the term "global variable" as just variables whose
scope is file scope?

"global" == "of, relating to, or applying to a whole"

That leaves open the present context of "whole".

Sometimes "whole" is a file.
Sometimes "whole" is a program.

I acknowledge the ambiguity.
I disambiguate according to present discussion.

 

[Joe Wright]

static? Standard certainly doesn't name them as such unless they are
explicitly declared with the static storage class specifier. I would
choose what the standard states over any book, anyday..

I was just looking for what people thought on the use of "global
variable" period, and if they thought it was a misleading term in
describing a variable whose scope is file scope and where the storage
is external..

You're missing something j. The term static has two meanings in C. In
terms of storage, it is memory which is allocated and defined at compile
time as opposed to automatic, which is memory allocated and defined at
run time.
Objects defined outside of any function block have static storage class
because they are allocated their memory by the compiler and exist in
memory as the program loads and before it executes. If you want an
object of that same storage class within a function block, you declare
it 'static'.

The second meaning: Things defined outside of function blocks, including
functions have static storage class and external linkage. This external
linkage exposes the names of these objects to the linker so that
references to the objects in other modules can be resolved. For example
'printf' is a function in libc.a with external linkage. This allows you
to use 'printf()' in your programs without actually defining it. The
linker will 'point' your printf call into the library. Now this is the
slightly confusing part, if you want hide your otherwise externally
linked static storage objects from the linker, you declare them
'static'.

In foo.c for example...

int x; /* x has static storage and external linkage */
int foo(int i) {
return x + i;
}

In bar.c for example...

int x; /* x has static storage and external linkage */
int bar(int i) {
return x - i;
}

Now this is a conflict the linker can't resolve. If each x should be
local to its module, in each module declare it 'static int x;'. This
does not change the storage class (still static) but removes its
external linkage. x is now invisible to the outside world.

If we want one x used by both functions we might leave foo.c alone and
in bar.c (and any other module that might use it) declare it 'extern int
x;'. This refers x to the one defined with external linkage in foo.c.

 

[Richard Heathfield]

Anyone here feel that "global variables" is misleading for variables
whose scope is file scope?

I think the term "variable" is misleading. I use the term "file scope
objects with external linkage".

"global" seems to imply global visibility,
while this isn't true for variables whose scope is file scope.

That depends whether these so-called "variables" are qualified as static. If
so, then they are not even potentially globally visible (by name), although
there's nothing to stop their address being exported.

File scope objects that are not statically qualified are potentially visible
across the whole program.

If you
have a variable whose scope is file scope in another translation unit,
you have to provide a local declaration to access that variable from
the other translation unit.

Yes. Just because you have your eyes shut, that doesn't make me invisible.

Also, I don't see "global variable" used once in the standard. So
would it be more correct to refer to such variables that are often
referred to with the term "global variable" as just variables whose
scope is file scope?

More "correct"? Well, I wouldn't care to venture an opinion on that. But to
avoid ambiguity, I try to avoid the terms "global" and "variable" whenever
I can.

 

[Samuel Barber]

Not a flaw. Objects defined outside any function, and functions
themselves have static storage class and external linkage. Declaring
them 'static' removes the external linkage without affecting storage
class.

Yes, that's the flaw. 'static' (internal linkage) ought to be the
default state, because the vast majority of globals and functions are
not meant to be public. So fastidious programmers put 'static' in
front of almost everything. And it's not just a matter of neatness; it
helps the compiler. For one thing, good compilers automatically inline
single-use functions - but only if they are declared 'static'.

The better way would have been to have "export" and "import" keywords
(or less clearly, "public" and "extern").

Sam