Globally declared arrays

[robin.bruce]

Hi guys,

I just tried to give advice to a colleague who has a problem program in
C, and I was interested to hear the thoughts of this forum on the
subject.

I've been an occasional programmer in C for about a year now, so by no
means an expert, so it would be good to know if I'm leading my
colleague down the wrong path.

The error he's having is fairly obscure and relates to our own function
calls communicating with our own hardware, so I won't go into details.
Basically, does this sound like a reasonable thing to say:

I noticed that my colleague was declaring local arrays on the stack,
and also that he had a number of global variables and even a global
array on the stack. The arrays on the stack total less than 64k
(win32). The global array is only a few k. I said that in my mind, it
was just plain bad practice to have a globally declared array and to
have arrays declared on the stack. I told him to redo the whole thing
with pointers, malloc() and free and then see if the problems vanish.

Does this seem a reasonable thing to advise or am I, as I suspect my
colleague believes, just being pedantic and splitting hairs?

Cheers,

Robin

 

[Eric Sosman]

[...]
I noticed that my colleague was declaring local arrays on the stack,
and also that he had a number of global variables and even a global
array on the stack.

All right, you've lost me. What is a "global array on
the stack?"

Let's note in passing that the C language has no "stack,"
nor anything called "global." On the other hand, both terms
are often used in informal discussions. "The stack" is usually
understood as a piece of memory where `auto' variables reside,
often mingled with some of the data used to call and return
from functions. "Global variable" usually means a variable
with `static' storage duration and external linkage, or less
frequently with `static' duration and internal linkage.

However, the two notions just don't go together very well.
An `auto' variable clearly does not have `static' storage
duration, nor does it have any linkage at all (neither internal
nor external), so it doesn't fit either of the usual informal
meanings of "global." Nor can I think of any reason for an
implementation to put `static'-duration objects on "the stack"
(indeed, there are good reasons not to). So: What, exactly,
do you mean by a "global array on the stack?"

The arrays on the stack total less than 64k
(win32). The global array is only a few k. I said that in my mind, it
was just plain bad practice to have a globally declared array and to
have arrays declared on the stack. I told him to redo the whole thing
with pointers, malloc() and free and then see if the problems vanish.

"Global" variables (by which I mean `static'-duration
variables with external linkage) offer the advantage of easy
access from anywhere in the program, with the corresponding
disadvantage of uncontrolled access from everywhere in the
program. They introduce "coupling" between modules, making
them less modular, so the decision to introduce a "global"
variable should be taken with care: Do the benefits of the
coupling outweight the drawbacks?

Once the decision to use a "global" variable has been
made, it really doesn't much matter what type of variable
it is: An `int', a pointer, an array, a struct, a whatever.
I see no advantage or disadvantage to a "global" array that's
any different from the advantages and disadvantages of other
types of "global" variables.

Does this seem a reasonable thing to advise or am I, as I suspect my
colleague believes, just being pedantic and splitting hairs?

Impossible to say. You've told us your colleague faces
a "fairly obscure" error, and you haven't mentioned the result
of any effort to diagnose it. If all you've got is a symptom
without any diagnosis or even hypothesis, then any change you
make amounts to "try something random; maybe it'll help." It's
the software equivalent of kicking your car in hopes that the
gas tank will refill itself.

A confession, though: Every so often I've confronted a
bug that has resisted my best attempts at analysis, and after
a period of frustration (and out of a desire to feel like I
was doing *something* of value) I've set about cleaning up
miscellaneous deficiencies -- stuff that has nothing to do
with the bug at hand, but "really ought to be fixed someday."
Once in a great while such unrelated housecleaning will "fix"
the bug; the kick shakes a quarter-teaspoon of gas out of the
fuel filter. So your hair-splitting might not be pedantry,
but desperation and an appeal to magic.

(Of course, an unexplained "magical" fix is less than
satisfactory. You'll be left wondering whether you've just
rearranged the memory layout a little, so the wild pointer
now clobbers memory that was about to be overwritten anyhow;
the bug may still be there, but rendered harmless -- until
somebody makes a perfectly innocent change somewhere else,
moving a different victim into the path of the wild pointer's
thunderbolt ...)

 

[robin.bruce]

[...]
I noticed that my colleague was declaring local arrays on the stack,
and also that he had a number of global variables and even a global
array on the stack.

All right, you've lost me. What is a "global array on
the stack?"

OK, before we go any further, I should point out the following:

"Global array on the stack" the words "on the stack" are a pure typo


I meant that he was declaring local arrays on the stack (or function
frame, or whatever). He was also declaring variables and arrays that
weren't local to any function (and therefore I meant to refer to them
as global). I didn't mean to say that the globally declared stuff was
on anything that might be referred to as a stack.