How to eliminate this global variable, silent?

[James Kuyper]

Nick Keighley wrote:
....

Def:
a variable is a binding between an identifier and an area of storage.

That doesn't fit conventional usage of the term. Consider a typical
usage: "This variable has a value of 3." While the binding is highly
relevant to the definition of the term 'variable', it is not what that
term directly refers to. Neither does it refer to the identifier that is
bound. The term variable refers to the object that is bound to the
identifier.

In much simpler terms: a variable is a named object.

....

Def:
global variable is an identifier with an unnecessarily large
visibility

That also does not fit conventional usage. You've taken a value judgment
about global variables, and converted that judgment into the definition.
Consider:

char* aaah(int n, char s[])
{
int i;
for(i=0; i<n; i++)
s = 'a';

return s+n;
}

According to your definition, 'i' is a global variable, because it is
visible at the return statement, which is not a place where it is
necessary for it to be visible. The function could have been re-written
to use:

for(int i=0; i<n; i++)

Personally, I like this C99 feature, and favor its use in any code that
is not required to be C90-compatible. However, that's a value judgment,
and shouldn't have anything to do with the definition of 'global variable'.

On the flip side, your definition could arguably be used to deny the
label 'global variable' to a variable with file scope and external
linkage, if the global visibility of that variable is in fact necessary.
Obviously, if you insist on the dogma that it can never be justified, no
such possibility exists. While I think that global variables are almost
always design errors, I insist on the word "almost" - there are exceptions.

In any event, the definition of whether or not something is a global
variable should not depend upon individual value judgments about the
merits of global visibility.

My own definition of 'global variable' in a C context is

"a variable whose identifier has file scope and external linkage"

I don't think file scope gives a variable sufficient visibility to
justify the the adjective 'global'. I don't think the fact that such
variables can be hidden by a local declaration is sufficient
justification to deny them that label.

As I've defined them, C has variables and in particular global
variables, even though the C standard itself provides no definitions for
either of those terms. That's no different from the fact that C has a
grammar, even though the C standard never defines the term 'grammar'.
The C standard doesn't have to be the source of the definition of every
term that it is useful to use while describing C.

 

[Richard Bos]

My own definition of 'global variable' in a C context is

"a variable whose identifier has file scope and external linkage"

I don't think file scope gives a variable sufficient visibility to
justify the the adjective 'global'.

A common beginner's question is: "Why does everybody say that global
objects are bad for recursive functions?" External linkage is entirely
irrelevant to that question. And that's why it is best to specify what
you mean when you ask about "global functions". In some cases, linkage
is important; in others, it isn't.

Richard

 

[Richard Tobin]

I have several further questions on global variables.

When are they used? I.e., in what situations it is good to use them.

It's obvious what's *good* about global variables: they're useful
whenever you want to use the same variable in lots of different parts
of the program.

The trouble is that you sometimes find that you want to take a program
and modify it or re-use it in a way that doesn't work with global
variables. For example, suppose you write a program to read a file,
and you use a global variable to store the FILE * that you read with
(quite natural because you use it in lots of places). Now you find
you want to read two files at once (one line from each at a time,
perhaps). You have to change the program to pass the FILE * around
as an argument.

So when should you use a global variable? When the simplicity and
convenience outweigh the difficulty of re-using the code. That's
not a technical question - it depends on your circumstances.

-- Richard

 

[Chris Dollin]

Chris Dollin said:

Clearly it is possible for an identifier to be associated with more than
one area of storage (trivial example: recursive function), so presumably
we can agree that identifiers and variables are not the same thing. But,
as Yevgen Muntyan has so rightly pointed out, scope is to do with
identifiers, not objects, and "global" is surely to do with scope, is it
not?

Not /just/ scope; there's an implication that the variable has
unbounded [ie until the program terminates] extent.

Okay, so that rules out auto - according to you, at any rate.

I wouldn't describe any C automatic variable as a "global variable"
without further qualification ("`x` is global to the entire 800
lines of the smudgereification function").

This in itself suggests that what is meant by "global" varies according to
the context - i.e. the semantics of "global" is local.

Parametrised, with the default being globally global.

Sure - but the test is: "are they useful?" I am not convinced that the
term "global variable" is sufficiently useful to overcome the fact that
nobody can tell us what one is.

I disagree here. "global variable", meaning one that can be accessed
by name & updated by any program component without the definer of the
name having any say in the matter [1],

This rules out static, which leaves extern (objects identified by an
identifier at file scope and with external linkage).

I covered this in the footnote.

And can we all agree on that? Are there any dissenters?

Is water wet? Do Eddorians crave power?

And when someone describes as "global" an identifier at file scope but with
*internal* linkage, is it okay to tell him he's wrong?

That depends. The variable is global to the file, but not (necessarily)
to the program. Which did they mean?

Communication beats definitional cat-vacuuming.

 

[James Kuyper]

A common beginner's question is: "Why does everybody say that global
objects are bad for recursive functions?" External linkage is entirely
irrelevant to that question. And that's why it is best to specify what
you mean when you ask about "global functions". In some cases, linkage
is important; in others, it isn't.

Well, as far as that goes, file scope is also irrelevant to that
question. Static storage duration is what's really relevant. Use of such
a variable is just as problematic in recursive functions whether it has
static storage duration because it's defined at file scope or because
it's explicitly declared with the 'static' keyword with block scope.

Therefore, "global variable" is the wrong term to use for that question.
There would be some value in defining a short phrase that means
"variable with static storage duration". The term "static variable" is
clearly unsuitable because it's ambiguous as to which meaning of
"static" it refers to. However, "global variable" is equally clearly not
the right short form for "variable with static storage duration".

I would use "file scope variables" in any context where file scope is
relevant, but external linkage is not. I would only use the term "global
variables" when both factors are relevant.

In fact, now that I think about it, the key issue is simply the fact
that the variable has external linkage. If it has such linkage, and is
defined in C code, then it necessarily has file scope in the C code
which defines it. However, an object with external linkage presents
precisely the same issues whether it was defined in C or in some other
language, even if the only declaration of it in C code has block scope:

int get_turn(void)
{ /* Silly example, just to clarify what I am referring to */
extern int turn_number;
return turn_number;
}

Therefore, I will simplify my definition. I use the phrase "global
variable" exclusively as a short form for "variable with external linkage".

 

[Richard Tobin]

Therefore, "global variable" is the wrong term to use for that question.
There would be some value in defining a short phrase that means
"variable with static storage duration". The term "static variable" is
clearly unsuitable because it's ambiguous as to which meaning of
"static" it refers to. However, "global variable" is equally clearly not
the right short form for "variable with static storage duration".

Surely "non-local" is the obvious term in this case. Problems with
variables in recursive functions are likely to hinge on whether of not
the variable is local to the function being recursively called;
exactly what its scope is if it's not local is unimportant.

Therefore, I will simplify my definition. I use the phrase "global
variable" exclusively as a short form for "variable with external linkage".

Yes, or if you want to get closer to the C standard's terminology
"object identifier with external linkage". But that is not the
definition of global variable, because the term is not exclusive to C.
It's just what global variables turn out to be in C, just as "strings"
turn out to be arrays of characters terminated by '\0'.

-- Richard

 

[Richard Tobin]

The single paragraph says an identifier is a name used to refer to any
of several things including objects. "An object, sometimes called a
variable, is a location in storage and its interpretation depends on two
main attributes: its storage class and its type." At least Brian
Kernighan thinks object and variable are interchangeable.

Human language has subtleties that are not always amenable to
precise definitions.

When you do

int *x = malloc(10 * sizeof(x));

you would probably agree that you are allocating an array of 10
objects. But would you say that you are allocating an array of
10 variables?

I wouldn't think of, say, the third int in the array as a variable.
But I might well call x[2] a variable. If f() returned x I would be
slightly less inclined to call f(x)[2] a variable. All quite
illogical in a sense, but that's the way it is. I call objects
variables when I think of them as named. And the more complicated the
expression, the less name-like it is.

I just checked with a very exerienced colleague, and he thinks
that "x" is a variable but "x[2]" isn't. So between him and K&R,
I think my position is a sensible, moderate one

-- Richard

 

[James Kuyper]

Surely "non-local" is the obvious term in this case. Problems with
variables in recursive functions are likely to hinge on whether of not
the variable is local to the function being recursively called;
exactly what its scope is if it's not local is unimportant.

Well, that's a different kind of problem than the one I was thinking of;
but non-local is certainly the right way to describe the variables it
applies to.

Yes, or if you want to get closer to the C standard's terminology
"object identifier with external linkage". But that is not the

Not quite. As I understand the term, it refers to the identified object,
not to the identifier of the object. What I'm talking about could be
described as an "object with an externally linked identifier".

definition of global variable, because the term is not exclusive to C.
It's just what global variables turn out to be in C, just as "strings"
turn out to be arrays of characters terminated by '\0'.

If you want "global variable" to be a language-independent term, that's
going to be a lot harder to define in a way that can be usefully applied
to the C language. The simplest language-independent definition I can
think of, "variable which is guaranteed to be visible from anywhere in a
program", has no C referent. That is because, as Richard Heathfield has
already pointed out, any variable can be rendered invisible in certain
parts of the program, by declaration of a variable with a different
scope and the same name. Such a variable isn't even visible in a given
translation unit if until it has been declared, and that declaration
could have block scope instead of file scope. I don't know of any simple
modification of that definition will allow it to refer to anything which
actually exists in C, without losing language independence.

I think it's much more useful to acknowledge that there's little that
can meaningfully be said about global variables that is language
independent, and that it's more useful to let the definition be language
specific.

 

[Keith Thompson]

[1] I am given to understand that "Antoninus Twink" has recently changed
his ways, and has started posting attempts at technical responses. If that
is the case, it is to be welcomed, and probably merits his exclusion from
'they'. Whether it is the case or not, however, it's probably best if he
stays in my killfile, for the sake of a quieter life for both of us.

He's started posting technical responses, but they've been uniformly
off-topic. It's mostly stuff that would probably be perfectly
appropriate in comp.unix.programmer. He's trying to encourage
system-specific discussions here in comp.lang.c. I believe this is
just a more subtle form of trolling. I'm at least mildly concerned
that it might actually work and cause some real damage to the
newsgroup.

 

[Richard]

Well, that's a different kind of problem than the one I was thinking
of; but non-local is certainly the right way to describe the variables
it applies to.

Like "non black" to describe white people? What a load of nonsense.

Not quite. As I understand the term, it refers to the identified
object, not to the identifier of the object. What I'm talking about
could be described as an "object with an externally linked
identifier".


If you want "global variable" to be a language-independent term,
that's going to be a lot harder to define in a way that can be
usefully applied to the C language. The simplest language-independent

Nonsense. declare "int i" outside of function scope. It's a global. To
give ACCESS to that global is another matter. The you provide the extern
OR, shock horror, some sort of registry access function which can return
a pointer to that global.

definition I can think of, "variable which is guaranteed to be visible
from anywhere in a program", has no C referent. That is because, as
Richard Heathfield has already pointed out, any variable can be
rendered invisible in certain parts of the program, by declaration of

So what? There is a coffee cup on my table. The fact that I chose to put
a pile of books in front of it doesn't make it any the less there.

a variable with a different scope and the same name. Such a variable
isn't even visible in a given translation unit if until it has been
declared, and that declaration could have block scope instead of file

So? It's still globally accessible where global mean "any other pleace
in the process/program" where access to that global is granted. It is
not "local" to any single function.

scope. I don't know of any simple modification of that definition will
allow it to refer to anything which actually exists in C, without
losing language independence.

I dont know you would want to have such.

I think it's much more useful to acknowledge that there's little that
can meaningfully be said about global variables that is language
independent, and that it's more useful to let the definition be
language specific.

I think its more useful to use the generally accepted term "global" and
not try to be too clever.

 

[Flash Gordon]

Keith Thompson wrote, On 16/04/08 17:59:

[1] I am given to understand that "Antoninus Twink" has recently changed
his ways, and has started posting attempts at technical responses. If that
is the case, it is to be welcomed, and probably merits his exclusion from
'they'. Whether it is the case or not, however, it's probably best if he
stays in my killfile, for the sake of a quieter life for both of us.

He's started posting technical responses, but they've been uniformly
off-topic. It's mostly stuff that would probably be perfectly
appropriate in comp.unix.programmer. He's trying to encourage
system-specific discussions here in comp.lang.c. I believe this is
just a more subtle form of trolling. I'm at least mildly concerned
that it might actually work and cause some real damage to the
newsgroup.

He has also on at least one occasion carefully snipped a post
redirecting someone to comp.unix.programmer so that it appeared to be a
request to post highly system specific code here instead.

 

[Flash Gordon]

Richard wrote, On 16/04/08 18:58:

Like "non black" to describe white people? What a load of nonsense.

No, rather as you could use "non black" to describe someone who could be
white, yellow, green or in fact anything other than white.

Nonsense. declare "int i" outside of function scope. It's a global. To
give ACCESS to that global is another matter. The you provide the extern
OR, shock horror, some sort of registry access function which can return
a pointer to that global.

Personally I would not consider a file scope object that does not have
external linkage to be a global. In another language I might call it a
"module local variable" or something similar since it is local to that
specific module.

I would say something more like, "a global variable is one that is
visible by name everywhere that it is not shadowed by another variable"
where a variable is approximately, "a named area of storage". These
definition would need tightening up a bit though.

I think its more useful to use the generally accepted term "global" and
not try to be too clever.

Based on the above your usage of the term "global" is not the same as
mine and I've met others who would agree with my usage.

 

[Richard]

Keith Thompson wrote, On 16/04/08 17:59:

[1] I am given to understand that "Antoninus Twink" has recently
changed his ways, and has started posting attempts at technical
responses. If that is the case, it is to be welcomed, and probably
merits his exclusion from 'they'. Whether it is the case or not,
however, it's probably best if he stays in my killfile, for the
sake of a quieter life for both of us.

He's started posting technical responses, but they've been uniformly
off-topic. It's mostly stuff that would probably be perfectly
appropriate in comp.unix.programmer. He's trying to encourage
system-specific discussions here in comp.lang.c. I believe this is
just a more subtle form of trolling. I'm at least mildly concerned
that it might actually work and cause some real damage to the
newsgroup.

He has also on at least one occasion carefully snipped a post
redirecting someone to comp.unix.programmer so that it appeared to be
a request to post highly system specific code here instead.

Your views on who is or is not a troll are off topic. Please take your
bitching offline to email where it belongs.

 

[lawrence.jones]

Variables, despite the name, don't have to vary.

Thus, the old saying: "Constants aren't. Variables won't."

-Larry Jones

I hope Mom and Dad didn't rent out my room. -- Calvin

 

[lawrence.jones]

As far as I know, the C standard does not define "variable".

It makes a normative reference to ISO/IEC 2382-1:1993, Information
Technology -- Vocabulary -- Part 1: Fundamental terms, which one would
expect to contain a definition. If anyone has access to that document,
it would be interesting to find out what it has to say.

-Larry Jones

I think your train of thought is a runaway. -- Calvin's Mom

 

[lawrence.jones]

Either you don't have the right books or you don't read enough. Please
refer to K&R2 Section A4. Meaning of Identifiers.

The single paragraph says an identifier is a name used to refer to any
of several things including objects. "An object, sometimes called a
variable, is a location in storage and its interpretation depends on two
main attributes: its storage class and its type." At least Brian
Kernighan thinks object and variable are interchangeable.

Section A is DMR, not BWK.

-Larry Jones

Hello, I'm wondering if you sell kegs of dynamite. -- Calvin

 

[jameskuyper]

Like "non black" to describe white people? What a load of nonsense.

I'm not sure what your point is - it would have been more helpful if
you had bothered to identify what makes it seem nonsensical to you.

I'll restrict my response to pointing out that your analogy is faulty.
I would use the word 'local' only to describe those variables which
have identifiers with function or block scope, and internal linkage. I
would only use the word 'global' to describe variables which have
identifiers with external linkage, regardless of scope. There's
clearly no overlap between those categories, but there's also quite
clearly many kinds of variables that don't fall into either category.
Therefore, I was endorsing the use of "non-local" as a term to
describe all of the variables that do not fall into the category
"local", whether or not they also fall into the category "global". The
appropriate analogy would be using using the term "non-black" to
describe white, asian and mixed-race people (among other
possibilities).

....

Nonsense. declare "int i" outside of function scope. It's a global. To
give ACCESS to that global is another matter. The you provide the extern
OR, shock horror, some sort of registry access function which can return
a pointer to that global.

OK. Now please accompany your example with a a language-independent
definition of "global variable" which applies to such a variable. A
list of examples is not a very good way to describe the elements of an
infinite set, or even one that is merely enormously large.

So what? There is a coffee cup on my table. The fact that I chose to put
a pile of books in front of it doesn't make it any the less there.

It does, however, make the coffee cup less visible. If you want to
define what a "global variable" is in terms other than visibility,
that's fine. Please present the definition.

So? It's still globally accessible where global mean "any other pleace
in the process/program" where access to that global is granted. It is
not "local" to any single function.

In common usage, "global" doesn't mean "non-local", it means
"everywhere on the globe". Could a cell-phone company properly claim
to provide global coverage, if they only cover countries whose names
start with the letters 'A'-'M'? They're surely not just a local
company, but they're not yet big enough to be called "global",

I dont know you would want to have such.

I don't know what you meant by that comment. I would like to have a
language-independent definition, but I know of no way to define one.
I'm willing to settle for a language-dependent definition, and I find
the particular language-dependent definition I've provided to be quite
useful.

If you think there's a better one, please provide it; but "I know one
when I see one" is pretty much the most useless definition I can
imagine.

I think its more useful to use the generally accepted term "global" and
not try to be too clever.

I would say that this is an accurate description of what I just did;
I'm using the generally accepted term, and I'm being clever enough to
understand that term in a manner that makes it useful in this context,
without being too clever. Obviously, you disagree, but it would be
more helpful if you'd explain why, and provide an alternative, rather
than merely rejecting it.

 

[Richard Tobin]

Well, that's a different kind of problem than the one I was thinking
of; but non-local is certainly the right way to describe the variables
it applies to.

[/QUOTE]

Like "non black" to describe white people? What a load of nonsense.

Non-local includes variables whose scope is less than global, for example
file-scope static variables in C and variables in containing scopes around
the recursive function in languages which support that (standard C doesn't
of course).

-- Richard

 

[Richard Tobin]

If you want "global variable" to be a language-independent term, that's
going to be a lot harder to define in a way that can be usefully applied
to the C language. The simplest language-independent definition I can
think of, "variable which is guaranteed to be visible from anywhere in a
program", has no C referent. That is because, as Richard Heathfield has
already pointed out, any variable can be rendered invisible in certain
parts of the program, by declaration of a variable with a different
scope and the same name. Such a variable isn't even visible in a given
translation unit if until it has been declared, and that declaration
could have block scope instead of file scope. I don't know of any simple
modification of that definition will allow it to refer to anything which
actually exists in C, without losing language independence.

The version I gave yesterday, which said something like "visible given
a suitable declaration" seems to cover it. I take "suitable declaration"
to imply "and not an (unsuitable) shadowing one", but you can spell
that out if you like.

In any case, I don't think it matters if there is some amount of
ambiguity to the term. The context usually makes it clear, or if
it doesn't you can ask for clarification. That's what you'd do in
a normal conversation, and I don't see why discussions in comp.lang.c
should be any different.

-- Richard

 

[Richard Tobin]

int *x = malloc(10 * sizeof(x));

[/QUOTE]

The canonical statement is:

int *x = malloc(10 * sizeof *x);

The missing star was of course just a mistake.

I didn't realize we were discussing your preferences rather than
accepted definitions of the term 'variable'.

Well, now you know.

-- Richard