auto vs. static vs. global (was: stack overflow ...)

[KW Heuer]

In article <226 at utrc-2at.UUCP> utrc-2at!jerry (Jerry J. Deroo) writes:
[ concerning stack overflows on certain machines ]
>this is yet another example of posted code's "all the world is a vax"
>syndrome.  I have run into the same thing on Plexus machines, and Pixels,
>and an Elxsi 6400 as well.

I've seen it happen on a vax too.  (Non-unix.)  To this day I try to avoid
auto arrays regardless of size.

>I got around it by looking for all large structures and arrays that
>were declared as dynamic variables in a function.. move their
>declaration outside the function body, maybe change the name, etc.

I've noticed a similar problem on the 3b2/300 running SVR2.  There are
four ways to declare an array:

[0] (inside function)  auto char buf[SIZ];
[1] (inside function)  static char buf[SIZ];
[2] (outside function) static char buf[SIZ];
[3] (outside function) char buf[SIZ];

In my program, SIZ was very large (and there were several arrays).
Methods [0] and [1] were not generally usable because some of the arrays
were shared among several functions; also [0] (assuming it doesn't cause
a stack overflow) would be initialized to garbage rather than zero.

Now, the scope of [1] is function, [2] is file, and [3] is program.  They
are otherwise identical, right?  Wrong.  The C compiler chose to put [1]
and [2] into the data segment, tagged with a generated label and explicitly
initialized to zero; only [3] goes into the bss segment, where it's tagged
with its true name (since it's global) and assigned a "value" which is
really its size, which the loader knows how to resolve.

All of which might have been merely a minor annoyance, except that I didn't
have enough disk space for the resulting .o files.  The workaround, of course,
was to use [3] for all such large arrays, after checking for name conflicts
in the rest of the program.

I just tried this on a SVR2 vax, and it did the same thing -- only [3] goes
into bss space.  This seems to reflect the relationship between the bss
segment and fortran common blocks.

Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint