Re: Global versus Stack variables

Dave Thompson <>
5 Dec 2005 02:54:51 -0500

          From comp.compilers

Related articles
Global versus Stack variables (shrey) (2005-11-19)
Re: Global versus Stack variables ( (2005-11-21)
Re: Global versus Stack variables (glen herrmannsfeldt) (2005-11-21)
Re: Global versus Stack variables (2005-11-21)
Re: Global versus Stack variables (2005-11-21)
Re: Global versus Stack variables (Jatin Bhateja) (2005-11-26)
Re: Global versus Stack variables (2005-11-26)
Re: Global versus Stack variables (Dave Thompson) (2005-12-05)
| List of all articles for this month |

From: Dave Thompson <>
Newsgroups: comp.compilers
Date: 5 Dec 2005 02:54:51 -0500
Organization: AT&T Worldnet
References: 05-11-094 05-11-096
Keywords: storage, analysis
Posted-Date: 05 Dec 2005 02:54:51 EST

On 21 Nov 2005 22:40:47 -0500, ""
<> wrote:

> * Dependency and data flow analysis is more practical with local
> variables as the compiler doesn't need to worry about the contained
> values changing between function calls (same holds for concurrent

It needs to worry _less_ about hidden changes. In algolian languages
other than C's immediate family, if a routine P calls its child C, or
another descendant S of P does so, locals in P can change.

> modification of variables). C bypasses these problems by assuming
> everything is is effectively local (during dependency, etc analysis)
> unless a var is declared volatile.

If by 'effectively local' you mean unaliasable, not true. Classical C
(following BCPL) assumed a classic global memory; standard C adds only
the restriction that accesses must use the correct type (within small
variations such as unsigned versus signed integer of the same rank)
_or_ a character (which in C means byte) type. E.g. an 'int' pointer
target (or object) can be assumed nonaliased with a 'float' one.

'volatile' was originally intended for things like memory-mapped I/O,
and may also be useful for multi-threading and particularly
multi-processing, although most if not all threading schemes (now)
have their own memory controls instead.

The 99 revision adds a new type of pointer qualification 'restrict'
which explicitly promises something is not aliased, effectively like
Fortran dummies/formals but for actual variables as well.

> int b[10], c;
> c=5;
> for(int i=0; i<=10; i++) b[i]=4;
> if(c==4) //a good optimizer should probably
> printf("Foo!");

A barely adequate optimizer should put c in a register or elide it
entirely and _not_ print Foo. And probably b[] and the loop, since
there are provably no reads from it in this trivial case.

Aside: standard C allows an implementation to require (because some
platforms do) that the last output to a text file, which stdout is,
end with a newline \n. But your example wasn't a whole program, and
this is irrelevant to the point at issue.

> Although yes, things like that are *probably* an error (and exceedingly
> dependant on the order of vars on the stack) :)
And alignment. Or more generally layout.

> --Oliver
> [Things like that are definitely an error if your program purports to be
> in ANSI C. -John]

Right. Or even just portable C, since stack layout has always been up
to the implementation and has in fact varied.

- David.Thompson1 at

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.