The '_' char in variable names

[Yoni Rabkin]

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?

 

[Serve La]

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.

 

[cody]

You can't use a variable name in your code with two underscores and

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.

 

[osmium]

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??

 

[Goran Larsson]

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.

 

[Serve La]

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

Yes, I see now that wasn't clear from my text.

 

[Chris Torek]

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?

[/QUOTE]

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.

 

[Jack Klein]

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

 

[those who know me have no need of my name]

in comp.lang.c i read:

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.

 

[Mark McIntyre]

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.

 

[Keith Thompson]

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).

 

[Dave Vandervies]

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:rintf("%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 (e-mail address removed)

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

 

[Serve La]

int main(void) {
int i;

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

for(j=0;j<17;j++) {
C:rintf("%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>