The term "global variables" misleading?

Discussion in 'C Programming' started by j, Jul 25, 2003.

  1. j

    j Guest

    Anyone here feel that "global variables" is misleading for variables
    whose scope is file scope? "global" seems to imply global visibility,
    while this isn't true for variables whose scope is file scope. If you
    have a variable whose scope is file scope in another translation unit,
    you have to provide a local declaration to access that variable from
    the other translation unit.

    Also, I don't see "global variable" used once in the standard. So
    would it be more correct to refer to such variables that are often
    referred to with the term "global variable" as just variables whose
    scope is file scope?
    j, Jul 25, 2003
    #1
    1. Advertising

  2. j

    j Guest

    Pieter Droogendijk <> wrote in message news:<>...
    > On 25 Jul 2003 09:49:32 -0700
    > (j) wrote:
    >
    > <snip>
    >
    > > Also, I don't see "global variable" used once in the standard. So
    > > would it be more correct to refer to such variables that are often
    > > referred to with the term "global variable" as just variables whose
    > > scope is file scope?

    >
    > They're called static or non-automatic. Reread your C book.


    static? Standard certainly doesn't name them as such unless they are
    explicitly declared with the static storage class specifier. I would
    choose what the standard states over any book, anyday..

    I was just looking for what people thought on the use of "global
    variable" period, and if they thought it was a misleading term in
    describing a variable whose scope is file scope and where the storage
    is external..
    j, Jul 26, 2003
    #2
    1. Advertising

  3. j

    Larry__Weiss Guest

    j wrote:
    > Anyone here feel that "global variables" is misleading for variables
    > whose scope is file scope? "global" seems to imply global visibility,
    > while this isn't true for variables whose scope is file scope. If you
    > have a variable whose scope is file scope in another translation unit,
    > you have to provide a local declaration to access that variable from
    > the other translation unit.
    >
    > Also, I don't see "global variable" used once in the standard. So
    > would it be more correct to refer to such variables that are often
    > referred to with the term "global variable" as just variables whose
    > scope is file scope?
    >


    "global" == "of, relating to, or applying to a whole"

    That leaves open the present context of "whole".

    Sometimes "whole" is a file.
    Sometimes "whole" is a program.

    I acknowledge the ambiguity.
    I disambiguate according to present discussion.
    Larry__Weiss, Jul 26, 2003
    #3
  4. j

    Joe Wright Guest

    j wrote:
    >
    > Pieter Droogendijk <> wrote in message news:<>...
    > > On 25 Jul 2003 09:49:32 -0700
    > > (j) wrote:
    > >
    > > <snip>
    > >
    > > > Also, I don't see "global variable" used once in the standard. So
    > > > would it be more correct to refer to such variables that are often
    > > > referred to with the term "global variable" as just variables whose
    > > > scope is file scope?

    > >
    > > They're called static or non-automatic. Reread your C book.

    >
    > static? Standard certainly doesn't name them as such unless they are
    > explicitly declared with the static storage class specifier. I would
    > choose what the standard states over any book, anyday..
    >
    > I was just looking for what people thought on the use of "global
    > variable" period, and if they thought it was a misleading term in
    > describing a variable whose scope is file scope and where the storage
    > is external..


    You're missing something j. The term static has two meanings in C. In
    terms of storage, it is memory which is allocated and defined at compile
    time as opposed to automatic, which is memory allocated and defined at
    run time.
    Objects defined outside of any function block have static storage class
    because they are allocated their memory by the compiler and exist in
    memory as the program loads and before it executes. If you want an
    object of that same storage class within a function block, you declare
    it 'static'.

    The second meaning: Things defined outside of function blocks, including
    functions have static storage class and external linkage. This external
    linkage exposes the names of these objects to the linker so that
    references to the objects in other modules can be resolved. For example
    'printf' is a function in libc.a with external linkage. This allows you
    to use 'printf()' in your programs without actually defining it. The
    linker will 'point' your printf call into the library. Now this is the
    slightly confusing part, if you want hide your otherwise externally
    linked static storage objects from the linker, you declare them
    'static'.

    In foo.c for example...

    int x; /* x has static storage and external linkage */
    int foo(int i) {
    return x + i;
    }

    In bar.c for example...

    int x; /* x has static storage and external linkage */
    int bar(int i) {
    return x - i;
    }

    Now this is a conflict the linker can't resolve. If each x should be
    local to its module, in each module declare it 'static int x;'. This
    does not change the storage class (still static) but removes its
    external linkage. x is now invisible to the outside world.

    If we want one x used by both functions we might leave foo.c alone and
    in bar.c (and any other module that might use it) declare it 'extern int
    x;'. This refers x to the one defined with external linkage in foo.c.
    --
    Joe Wright mailto:
    "Everything should be made as simple as possible, but not simpler."
    --- Albert Einstein ---
    Joe Wright, Jul 26, 2003
    #4
  5. j wrote:

    > Anyone here feel that "global variables" is misleading for variables
    > whose scope is file scope?


    I think the term "variable" is misleading. I use the term "file scope
    objects with external linkage".

    > "global" seems to imply global visibility,
    > while this isn't true for variables whose scope is file scope.


    That depends whether these so-called "variables" are qualified as static. If
    so, then they are not even potentially globally visible (by name), although
    there's nothing to stop their address being exported.

    File scope objects that are not statically qualified are potentially visible
    across the whole program.

    > If you
    > have a variable whose scope is file scope in another translation unit,
    > you have to provide a local declaration to access that variable from
    > the other translation unit.


    Yes. Just because you have your eyes shut, that doesn't make me invisible.
    :)


    > Also, I don't see "global variable" used once in the standard. So
    > would it be more correct to refer to such variables that are often
    > referred to with the term "global variable" as just variables whose
    > scope is file scope?


    More "correct"? Well, I wouldn't care to venture an opinion on that. But to
    avoid ambiguity, I try to avoid the terms "global" and "variable" whenever
    I can.

    --
    Richard Heathfield :
    "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
    C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
    K&R answers, C books, etc: http://users.powernet.co.uk/eton
    Richard Heathfield, Jul 26, 2003
    #5
  6. Joe Wright <> wrote in message news:<>...
    > Samuel Barber wrote:
    > > By the way, this brings up a flaw in C. External variables and
    > > (especially) functions should be 'static' by default.
    > >

    > Not a flaw. Objects defined outside any function, and functions
    > themselves have static storage class and external linkage. Declaring
    > them 'static' removes the external linkage without affecting storage
    > class.


    Yes, that's the flaw. 'static' (internal linkage) ought to be the
    default state, because the vast majority of globals and functions are
    not meant to be public. So fastidious programmers put 'static' in
    front of almost everything. And it's not just a matter of neatness; it
    helps the compiler. For one thing, good compilers automatically inline
    single-use functions - but only if they are declared 'static'.

    The better way would have been to have "export" and "import" keywords
    (or less clearly, "public" and "extern").

    Sam
    Samuel Barber, Jul 27, 2003
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Raoul Gough
    Replies:
    4
    Views:
    320
    Raoul Gough
    Aug 21, 2003
  2. Brian Kelley

    Misleading Python error message

    Brian Kelley, Nov 19, 2003, in forum: Python
    Replies:
    4
    Views:
    364
    Dennis Lee Bieber
    Nov 21, 2003
  3. Juho Schultz
    Replies:
    2
    Views:
    292
    Alex Martelli
    Jan 26, 2006
  4. misleading prefix ++

    , May 20, 2006, in forum: Python
    Replies:
    6
    Views:
    373
    Carl Friedrich Bolz
    May 21, 2006
  5. Claudio Grondi
    Replies:
    8
    Views:
    790
    Georg Brandl
    Aug 28, 2006
Loading...

Share This Page