It can be global within the context of what you are talking about.
If I write a shared library I can create a global variable within the context
of that shared library. That global variable need not be visible outside of
the shared library though. eg to applications linked to it. It is still a
global variable - it just that the library, and all its class, routines etc
are the only direct clients of the global. As C doesn't have Eiffel's
selective export, library boundries are often the equivalent.
For example, a cross platform GUI library might have a global variable for
Display if it's the X11 implementation. Clearly Display won't be available to
clients of the library as they should use cross platform interface. However,
it is still global to the entire library.
If you are talking within the context of a shared library or a single source
file it is fine to talk about a global (even if it can't be accessed from
anywhere) if you qualify that that's what you mean or if it is obvious
anyway. If your "globe" only consists of one source file, or a library etc
then a global within that context means just that.
When one refers to a global outside of any context and not qualified then
obviously one means a global avaiable to everyone. This is in fact the most
common kind I have found anyway. eg EV_APPLICATION has one instance and it is
available to all clients.
When I used the term global before that is exactly what I meant - available to
everyone. It is the most common kind.
I only use globals for creating singleton instances. It is most often the case
that this singleton is generic enough to be used from any client.
Unfortunately there isn't another term that I can think of for globals with
selective export (shared object in Eiffel). Other languages don't have
selective export and I guess that's why there isn't a term for it.
In C one should really call a global variable within a source file a static
variable I guess but I would still call a global variable whose scope was
limited to a library a global variable.