I agree that my use of the word "global" in this context is suboptimal.

The classic example is a project I was on 20 odd years ago where the project leader had been told that using global variables (in C) was considered a no-no. So, his 'fix' to avoid globals was that instead of this:

// projdata.h
int something;
char filename[255];
...
// projlib.c
#include "projdata.h"

int somefunc() {
   ...
   strupr( filename );
   ...
   return 0;
}

void someotherfunc ( int n ) {
    ...
    something = n;
    ...
    return;
}
[download]

We had:

// projdata.h
struct {
    int something;
    char filename[255];
    ...
} projdata, *pprojdata;

// projlib.c
#include "projdata.h"

int somefunc( pprojdata p ) {
   ...
   strcat( p->filename, ... );
   ...
   return 0;
}

void someotherfunc ( pprojdata p, int n ) {
    ...
    p->something = n;
    ...
    return;
}

// main.c

int main ( ... ) 
    projdata pd;
    int n;
    ...
    n = somefunc( &pd );
    ...
    someotherfunc( &pd, n );
    ...
}
[download]

Everything was simply wrapped in a huge struct a pointer to which got passed to every subroutine in the project. That code may seem far-fetched, but beleive, it's like is not so far away even today.

He'd avoided using global variables, but still all the program state was "global" in scope, even though it actually resided on the stack and so was local (auto) to main.

Global is not the right term here, but I cannot think of a better term?