The '_' char in variable names

Discussion in 'C Programming' started by Yoni Rabkin, Oct 11, 2003.

  1. Yoni Rabkin

    Yoni Rabkin Guest

    Upon meandering through source code I noticed a large amount of
    preprocessor constants with one or two '_' characters prefixed and
    postfixed to them. For example: __SYSCORE__ or __IND86__.

    What do the '__' before and after the constant supposed to denote?
    Why put them there?
    Yoni Rabkin, Oct 11, 2003
    #1
    1. Advertising

  2. Yoni Rabkin

    Serve La Guest

    On Sat, 11 Oct 2003 11:04:07 +0200, Yoni Rabkin
    <> wrote:

    >Upon meandering through source code I noticed a large amount of
    >preprocessor constants with one or two '_' characters prefixed and
    >postfixed to them. For example: __SYSCORE__ or __IND86__.
    >
    >What do the '__' before and after the constant supposed to denote?
    >Why put them there?


    Names starting with two underscores are reserved for the C compiler
    builders.
    You can't use a variable name in your code with two underscores and
    expect it to work on all compilers.
    Serve La, Oct 11, 2003
    #2
    1. Advertising

  3. Yoni Rabkin

    cody Guest

    > > You can't use a variable name in your code with two underscores and
    > > expect it to work on all compilers.

    >
    > I thought the rule applied to *leading* underscores??


    within variable names you can use underscores as you want like:

    my_funny_variable

    but you should avoid using leading underscores like:

    _iam_great

    or

    __iamgreater

    but all in all, this is just conventio to prevent name clashes, you are not
    forced to care for this recommendation.

    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
    cody, Oct 11, 2003
    #3
  4. Yoni Rabkin

    osmium Guest

    Serve La writes:

    > You can't use a variable name in your code with two underscores and
    > expect it to work on all compilers.


    I thought the rule applied to *leading* underscores??
    osmium, Oct 11, 2003
    #4
  5. In article <bm9204$jt26n$-berlin.de>,
    cody <> wrote:

    > but all in all, this is just conventio to prevent name clashes, you are not
    > forced to care for this recommendation.


    Recommendation? The ANSI/ISO/IEC 9899-1999 standard is clearly
    reserving (almost all) identifiers with leading underscores for use by
    the implementation. This means that such identifiers shall not be
    created by the programmer. You can ignore this standard, but then your
    program is no longer C.

    --
    Göran Larsson http://www.mitt-eget.com/
    Goran Larsson, Oct 11, 2003
    #5
  6. Yoni Rabkin

    Serve La Guest

    On Sat, 11 Oct 2003 07:47:09 -0700, "osmium" <>
    wrote:

    >Serve La writes:
    >
    >> You can't use a variable name in your code with two underscores and
    >> expect it to work on all compilers.

    >
    >I thought the rule applied to *leading* underscores??
    >


    Yes, I see now that wasn't clear from my text.
    Serve La, Oct 11, 2003
    #6
  7. Yoni Rabkin

    Chris Torek Guest

    >On Sat, 11 Oct 2003 11:04:07 +0200, Yoni Rabkin
    ><> wrote:
    >>Upon meandering through source code I noticed a large amount of
    >>preprocessor constants with one or two '_' characters prefixed and
    >>postfixed to them. For example: __SYSCORE__ or __IND86__.
    >>
    >>What do the '__' before and after the constant supposed to denote?
    >>Why put them there?


    In article <>
    Serve La <> writes:
    >Names starting with two underscores are reserved for the C compiler
    >builders.
    >You can't use a variable name in your code with two underscores and
    >expect it to work on all compilers.


    With some exceptions, a more general version of this applies: you
    cannot use any identifiers with a leading single underscore followed
    by an uppercase letter. (The exceptions include the wretched names
    _IOFBF, _IOLBF, and _IONBF that programmers are to supply to the
    setbuf() function.)

    It might be more interesting to consider, instead of "what" the
    precise rules are -- these can be found in the C standard -- "why"
    these rules exist.

    Most people reading this are probably "programmers writing C
    programs". As an individual, or a member of a programming team,
    you will need to use various identifiers to name functions, local
    variables, external variables, structures, structure members, and
    so on. But consider the person or persons writing the C compiler
    (including C library) that you are using. If they are writing some
    or all of the support code in C, they too need to use various
    identifiers to name functions, variables, structures, and so on.

    When I wrote 64-bit integer support for 4.xBSD, I used a slightly
    modified version of Knuth's "Program D" (vol 2, 2nd ed., section
    4.3.1, pp. 257--259) to compute "long long dividend / long long
    divisor", giving both a quotient and a remainder. But GCC wants
    to call this as __divdi3() for quotient only, and __moddi3() for
    remainder only. (Note that the C compiler has already dictated
    the form of the names of the support routines, and used these double
    underscores.) What should I name my "divide giving both quotient
    AND remainder" function so that I can call it from __divdi3 and
    __moddi3 as needed?

    If I used a name like "qdivrem", I would be taking a name that is
    reserved to *you*, the programmer(s) writing programs in C.
    Fortunately, I have a name-space reserved to *me* -- the implementor
    -- so I can just name the function __qdivrem(), which is what I
    did.

    If "application programmers" use only "their" names, and "implementation
    programmers" keep to theirs, neither group will ever "step on" the
    other by mistake.

    Note that this leaves "third-party library" writers in a bit of a
    bind. If you are writing, say, a new compression library, or
    routines to do Fourier transforms, or a matrix library, or any
    other reasonably "package-able" set of routines, what names can
    *you* use without colliding with either the implementor or the
    application programmer? You are stuck -- there is no name space
    reserved to you. The best you can do, which actually turns out to
    be pretty good (at least in C99 where the annoying "six monocase
    characters" restriction is gone), is to pick a prefix in the "user"
    (application programmer, "not-implementor") name space, and attach
    that to everything you write. An end-user who wants to use your
    library can simply avoid using that prefix. If you go with at
    least two or three letters, it will probably not be too annoying.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Oct 11, 2003
    #7
  8. Yoni Rabkin

    Jack Klein Guest

    On Sat, 11 Oct 2003 14:07:35 +0200, Serve La <> wrote
    in comp.lang.c:

    > On Sat, 11 Oct 2003 11:04:07 +0200, Yoni Rabkin
    > <> wrote:
    >
    > >Upon meandering through source code I noticed a large amount of
    > >preprocessor constants with one or two '_' characters prefixed and
    > >postfixed to them. For example: __SYSCORE__ or __IND86__.
    > >
    > >What do the '__' before and after the constant supposed to denote?
    > >Why put them there?

    >
    > Names starting with two underscores are reserved for the C compiler
    > builders.


    ....and for the language itself, such as __FILE__, __LINE__, and
    several others.

    > You can't use a variable name in your code with two underscores and
    > expect it to work on all compilers.


    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c /faq
    Jack Klein, Oct 11, 2003
    #8
  9. in comp.lang.c i read:
    >In article <>
    >Serve La <> writes:


    >>You can't use a variable name in your code with two underscores and
    >>expect it to work on all compilers.

    >
    >With some exceptions, a more general version of this applies: you
    >cannot use any identifiers with a leading single underscore followed
    >by an uppercase letter


    .... or another underscore.

    >It might be more interesting to consider, instead of "what" the
    >precise rules are -- these can be found in the C standard -- "why"
    >these rules exist.


    [excellent summary of the namespace issue: why they are useful]

    if only the separation were more pervasive. as the c standard evolves it
    routinely intrudes on the client's namespace, long after having made the
    underscore reservation, i.e., almost all the new identifiers added by c99
    should have been in the reserved space. of course reality intrudes, as you
    noted -- it makes for ugly identifiers, e.g., _Creal(), _Cimag() and
    _Cproj() -- such ugliness makes it easy for a committee to decide on
    creal(), cimag() and cproj(), even if there is a fair chance of a
    collision. the rationale goes: the names chosen are what one would
    naturally have called them, so the collisions would mostly be against
    functions with identical intent. the down side is a c99 compiler now
    *knows* what creal() is supposed to do, whether <complex.h> is included or
    not, so if there is any semantic difference (between your actual function
    and the code the compiler produces) it may not be exposed until the program
    misfunctions and that is detected.

    --
    a signature
    those who know me have no need of my name, Oct 11, 2003
    #9
  10. On Sat, 11 Oct 2003 15:53:21 +0200, in comp.lang.c , "cody"
    <> wrote:

    >but all in all, this is just conventio to prevent name clashes, you are not
    >forced to care for this recommendation.


    Actually, you are. At least if you want to write legal C.

    --
    Mark McIntyre
    CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
    CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>


    ----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
    http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
    ---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
    Mark McIntyre, Oct 11, 2003
    #10
  11. those who know me have no need of my name <> writes:
    [...]
    > if only the separation were more pervasive. as the c standard evolves it
    > routinely intrudes on the client's namespace, long after having made the
    > underscore reservation, i.e., almost all the new identifiers added by c99
    > should have been in the reserved space. of course reality intrudes, as you
    > noted -- it makes for ugly identifiers, e.g., _Creal(), _Cimag() and
    > _Cproj() -- such ugliness makes it easy for a committee to decide on
    > creal(), cimag() and cproj(), even if there is a fair chance of a
    > collision. the rationale goes: the names chosen are what one would
    > naturally have called them, so the collisions would mostly be against
    > functions with identical intent. the down side is a c99 compiler now
    > *knows* what creal() is supposed to do, whether <complex.h> is included or
    > not, so if there is any semantic difference (between your actual function
    > and the code the compiler produces) it may not be exposed until the program
    > misfunctions and that is detected.


    If only namespaces had been implemented as true namespaces, not as
    ugly little spelling conventions. Assuming C++-style syntax,
    everything in the standard library could have been C::foo (for various
    values of foo). Each implementer could have its own top-level
    namespace: gcc::, posix::, etc. Individual programmers could use
    whatever identifiers they want, as long as they don't conflict with
    keywords (introducing new keywords would still be a problem).

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
    Schroedinger does Shakespeare: "To be *and* not to be"
    Keith Thompson, Oct 12, 2003
    #11
  12. In article <>, Keith Thompson <> wrote:

    >If only namespaces had been implemented as true namespaces, not as
    >ugly little spelling conventions. Assuming C++-style syntax,
    >everything in the standard library could have been C::foo (for various
    >values of foo). Each implementer could have its own top-level
    >namespace: gcc::, posix::, etc. Individual programmers could use
    >whatever identifiers they want, as long as they don't conflict with
    >keywords (introducing new keywords would still be a problem).


    Hmm...

    --------
    preprocessor::include <stdio.h>

    keyword::int main(keyword::void)
    {
    using keyword::for;
    using keyword::int;

    int i;

    for(i=0;i<42;i++)
    {
    int j;

    for(j=0;j<17;j++)
    {
    C::printf("%d\t%d\n",i,j);
    }
    }

    keyword::return 0;
    }
    --------

    'Twould be ugly, and probably a nightmare to write a parser for, but I
    could see it working...


    dave
    (who really should go get some sleep instead of posting crazy ideas
    to usenet)

    --
    Dave Vandervies
    >till not good enough for Richard Heathfield, but what can you do, really?

    You could always write "only for clever people" on the cover.
    --Ben Pfaff and Richard Heathfield in comp.lang.c
    Dave Vandervies, Oct 12, 2003
    #12
  13. Yoni Rabkin

    Serve La Guest

    "Dave Vandervies" <> wrote in message
    news:bmahhf$a6r$...
    > int main(void) {
    > int i;
    >
    > for(i=0;i<42;i++)
    > {
    > int j;
    >
    > for(j=0;j<17;j++) {
    > C::printf("%d\t%d\n",i,j);
    > }
    > }
    >
    > return 0;
    > }


    Only using the namespace construct for variable names improves this a lot.
    Using them for keywords is over the top, it's not like a new standard
    introduces 50 new keywords.

    <ot>
    By the way, I had some problem once when porting a C++ program to a newer
    version of the same compiler.
    In an attempt to comply to the C++ standard they implemented digraphs.
    The old code had something like this:
    X<::Y> x; and this gave me a really weird error message. (Spot the digraph)
    adding a space fixed it.
    If this construct will ever be added to C, this could be a problem.
    </ot>
    Serve La, Oct 12, 2003
    #13
    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. wwj
    Replies:
    7
    Views:
    538
  2. wwj
    Replies:
    24
    Views:
    2,477
    Mike Wahler
    Nov 7, 2003
  3. wanwan
    Replies:
    3
    Views:
    415
    Alex Martelli
    Oct 14, 2005
  4. lovecreatesbeauty
    Replies:
    1
    Views:
    1,007
    Ian Collins
    May 9, 2006
  5. News123
    Replies:
    2
    Views:
    456
    John Machin
    Nov 26, 2008
Loading...

Share This Page