🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: net.bugs
Article #527

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

#527
From: KW Heuer
Date: Tue, 08 Apr 1986 15:59
43 lines
2673 bytes
In article <226@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
Technical Details
Message-ID: <697@bentley.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!uwvax!topaz!bentley!kwh
References: <226@utrc-2at.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!uwvax!topaz!bentley!kwh
From: kwh@bentley.UUCP (KW Heuer)
Newsgroups: net.bugs
Subject: auto vs. static vs. global (was: stack overflow ...)
Message-ID: <697@bentley.UUCP>
Date: Tue, 8-Apr-86 10:59:56 EST
Article-I.D.: bentley.697
Posted: Tue Apr  8 10:59:56 1986
Date-Received: Thu, 10-Apr-86 07:25:57 EST
References: <226@utrc-2at.UUCP>
Organization: AT&T Bell Laboratories, Liberty Corner
Lines: 43