_ and __ significance

[g.ankush1]

I have seen many variables or structures declared as _ or __ prefixed .
Can anyone explain the significance of _ or __ particularly . I mean ,
I wanted to know the convention for using _ and __ .

[Richard Heathfield]

kondal said:

<snip>

I used the phrase 'general convention' because C language doesn't stop
me in using a underscore in variables.

It does, however, warn you off from using them at the beginning of your
identifier names. In 1977, a 19-year-old trackside fire marshal - Jansen
van Vuuren - followed the "general convention" (anyone coming? No, okay, so
it must be safe to cross, right?), and crossed Kyalami carrying a fire
extinguisher. In so doing, he invaded racing-car space. Tom Pryce's car
struck him a second or two later. Both Pryce and van Vuuren were killed.

Stay out of implementation namespace.

How can you say it is reserved
namespace only for the C language standard and usable only by the C
language implementors.

4.1.2: "All external identifiers that begin with an underscore are reserved.
All other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[kondal]

Richard Heathfield wrote:

kondal said:

<snip>

I used the phrase 'general convention' because C language doesn't stop
me in using a underscore in variables.

It does, however, warn you off from using them at the beginning of your
identifier names. In 1977, a 19-year-old trackside fire marshal - Jansen
van Vuuren - followed the "general convention" (anyone coming? No, okay, so
it must be safe to cross, right?), and crossed Kyalami carrying a fire
extinguisher. In so doing, he invaded racing-car space. Tom Pryce's car
struck him a second or two later. Both Pryce and van Vuuren were killed.

Stay out of implementation namespace.

How can you say it is reserved
namespace only for the C language standard and usable only by the C
language implementors.

4.1.2: "All external identifiers that begin with an underscore are reserved.
All other identifiers that begin with an underscore and either an
upper-case letter or another underscore are reserved."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

Thank you. Can you tell me which C compiler is close to C spec? I
generally use gcc and it didn't give me any warning.

-kondal

[Richard Heathfield]

kondal said:

>
Richard Heathfield wrote:

>kondal said:

<snip>

>>

How can you say it is reserved
namespace only for the C language standard and usable only by the C
language implementors.

4.1.2: "All external identifiers that begin with an underscore are
reserved. All other identifiers that begin with an underscore and either
an upper-case letter or another underscore are reserved."

Thank you. Can you tell me which C compiler is close to C spec? I
generally use gcc and it didn't give me any warning.

C compilers are only required to give diagnostic messages for syntax errors
and constraint violations. Invading implementation namespace is neither of
those, so no message is required.

You have *had* your warning, right there in 4.1.2: "Don't. Do. This." You
shouldn't need another.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[kondal]

Richard Heathfield wrote:

kondal said:

Richard Heathfield wrote:

kondal said:

<snip>

>
How can you say it is reserved
namespace only for the C language standard and usable only by the C
language implementors.

4.1.2: "All external identifiers that begin with an underscore are
reserved. All other identifiers that begin with an underscore and either
an upper-case letter or another underscore are reserved."

Thank you. Can you tell me which C compiler is close to C spec? I
generally use gcc and it didn't give me any warning.

C compilers are only required to give diagnostic messages for syntax errors
and constraint violations. Invading implementation namespace is neither of
those, so no message is required.

You have *had* your warning, right there in 4.1.2: "Don't. Do. This." You
shouldn't need another.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

OK, I understand.

It does, however, warn you off from using them at the beginning of your

identifier names.

My curiosity is to know which C compiler gives the warning. If it is
defined only in C spec and not used by the compilers then what is the
use? I do not want to initiate any argument here, it could just be that
nobody cares about it.

I've seen lot of source codes which use underscores for structure names
and variables. as I said gcc (v 3.2.2) doesn't produce any warning.

-kondal

[Richard Heathfield]

kondal said:

>
Richard Heathfield wrote:

>It does, however, warn you off from using them at the beginning of your

identifier names.

My curiosity is to know which C compiler gives the warning.

No, the *Standard* warns you off from using leading underscores.

If it is
defined only in C spec and not used by the compilers then what is the
use?

The C compilers DO use identifiers with leading underscores, and that's why
you shouldn't.

Look, it's very simple.

You stay over here. The compiler writer stays over there. You don't get in
his way, and he won't get in yours. Easy.

I do not want to initiate any argument here, it could just be that
nobody cares about it.

Well, I care about not using identifiers that the implementation uses,
because I would like my programs to work. If you don't need your programs
to work, there is no need for you to care.

I've seen lot of source codes which use underscores for structure names
and variables. as I said gcc (v 3.2.2) doesn't produce any warning.

As I've said, it doesn't have to. You had your warning already, in the C
Standard. If you can't be bothered to pay attention to that warning, why
would you bother to pay any attention to gcc's warning, were it to give
one?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Bart]

kondal wrote:

OK, I understand.

I don't think so.

My curiosity is to know which C compiler gives the warning. If it is
defined only in C spec and not used by the compilers then what is the
use?

How would a compiler know when to give a warning? Let's say you
#include <stdio.hin your program and that header declares names such
as _iobuf, how would the compiler distinguish between code that you
wrote and code from the standard header?

I've seen lot of source codes which use underscores for structure names
and variables. as I said gcc (v 3.2.2) doesn't produce any warning.

The code of your standard library is not a good example to follow. As
mentionned before, those who write <stdio.hand other standard library
headers are allowed to use names that begin with underscores. You are
not allowed to use those same names. In this way, you don't conflict
with them.

Regards,
Bart.

[Clever Monkey]

Richard Heathfield wrote:

kondal said:

>Richard Heathfield wrote:

[...]

>I've seen lot of source codes which use underscores for structure names
and variables. as I said gcc (v 3.2.2) doesn't produce any warning.

As I've said, it doesn't have to. You had your warning already, in the C
Standard. If you can't be bothered to pay attention to that warning, why
would you bother to pay any attention to gcc's warning, were it to give
one?

Well, not everyone has committed every paragraph of the Standard to
memory (or can tease out the meaning in all the paragraphs if they had!)
In this case one would not know they have violated the Standard, even
if they were the type of person who might otherwise pay attention to a
diagnostic.

It does not follow that accidental ignorance of some paragraphs
indicates that the coder is more likely to ignore an honest-to-gods
diagnostic.

Simply put, even coders familiar with a good chunk of the Standard may
just know that an underscore is a valid identifier character and that
they've seen the identifier used in some specific cases. This might
lead to the incorrect assumption that this is merely a naming convention
(much like commenting styles, or brace placement, or Hungarian notation).

Perhaps I'm admitting to some terrible sin, but I will never commit the
entire Standard to memory, and know that even if I did I might come up
with some creative misunderstandin gs on implementation.

So, it follows that I will continue to discover new aspects of the
language and correct incorrect assumptions over time. Since I sometimes
try to participate in Real Life, and only partly spend my time with C,
this is a reasonable limitation I've learned to accept!

This does not mean that I would necessarily ignore a diagnostic.

[Richard Heathfield]

Clever Monkey said:

<snip>

>
So, it follows that I will continue to discover new aspects of the
language and correct incorrect assumptions over time. Since I sometimes
try to participate in Real Life, and only partly spend my time with C,

There's your problem right there! ;-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Mark McIntyre]

On 25 Sep 2006 23:50:39 -0700, in comp.lang.c , "kondal"
<ko******@gmail .comwrote:

>It does, however, warn you off from using them at the beginning of your

identifier names.

My curiosity is to know which C compiler gives the warning.

None, to my knowledge.

>If it is
defined only in C spec and not used by the compilers then what is the
use?

Compiler and C standard library writers can use it in their code.

>I've seen lot of source codes which use underscores for structure names
and variables. as I said gcc (v 3.2.2) doesn't produce any warning.

Its not required to.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan