underscore names

O

ok

I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that names
starting with underscores are reserved for the implementation. I decided not
to because it would make me look like somebody who just wastes other
people's time instead of finding real bugs.
Come on, how serious should we take this rule? This wont ever be an issue
 
V

Vladimir S. Oka

ok said:
I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that
names starting with underscores are reserved for the implementation. I
decided not to because it would make me look like somebody who just
wastes other people's time instead of finding real bugs.
Come on, how serious should we take this rule?

Very serious(ly)!
This wont ever be an issue

It is, and a big one at that. C&V 7.1.3p1:

Each header declares or deï¬nes all identiï¬ers listed in its associated
subclause, and optionally declares or deï¬nes identiï¬ers listed in its
associated future library directions subclause and identiï¬ers which are
always reserved either for any use or for use as ï¬le scope identiï¬ers.

— All identiï¬ers that begin with an underscore and either an uppercase
letter or another underscore are always reserved for any use.
— All identiï¬ers that begin with an underscore are always reserved for
use as identiï¬ers with ï¬le scope in both the ordinary and tag name
spaces.

PS
Are you sure you're not trolling?
 
R

Ron Lima

I started thinking a bit if I should tell the author of that code that names
starting with underscores are reserved for the implementation.

I think that the convention about names says that names starting with
underscores and with the first non-underscore letter capitalized are
reserved for the implementation of the C library. I saw a suggestion
made by P.J. Plauger on his book "STD C Library".

Particularly I avoid naming variables with underscores as first
characters because I had problems in the past with Tru64 C library
implementation. However I'm not sure if you should worry about it. A
lot of people use underscores to start names they consider "internal"
and are not intended to be exported.
 
E

Eric Sosman

ok wrote On 03/01/06 13:13,:
I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that names
starting with underscores are reserved for the implementation. I decided not
to because it would make me look like somebody who just wastes other
people's time instead of finding real bugs.
Come on, how serious should we take this rule? This wont ever be an issue

You are *so* right! Down with the pedants! Just for
the sake of interest, though, would you try the following
program on your system and tell us what the output is?

#include <assert.h>
#include <ctype.h>
#include <errno.h>
#include <float.h>
#include <inttypes.h>
#include <iso646.h>
#include <limits.h>
#include <locale.h>
#include <math.h>
#include <setjmp.h>
#include <signal.h>
#include <stdarg.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <time.h>
#include <wchar.h>
#include <wctype.h>

int __EXTENSIONS__ = __LINE__;
int __MATHERR_ERRNO_DONTCARE = __LINE__;
int __P = __LINE__;
int __PRAGMA_REDEFINE_EXTNAME = __LINE__;
int ___errno = __LINE__;
int __assert = __LINE__;
int __buf = __LINE__;
int __filbuf = __LINE__;
int __flsbuf = __LINE__;
int __flt_rounds = __LINE__;
int __fltrounds = __LINE__;
int __i386 = __LINE__;
int __ia64 = __LINE__;
int __lint = __LINE__;
int __longlong_t = __LINE__;
int __posix_asctime_r = __LINE__;
int __posix_ctime_r = __LINE__;
int __posix_sigwait = __LINE__;
int __setp = __LINE__;
int __sigev_pad2 = __LINE__;
int __signo = __LINE__;
int __sparc = __LINE__;
int __strptime_dontzero = __LINE__;
int __time = __LINE__;
int __tm = __LINE__;
int __va_list = __LINE__;

#define SHOW(x) printf("%s == %d\n", STRING(x), x);

int main(void)
{
SHOW(__EXTENSIONS__);
SHOW(__MATHERR_ERRNO_DONTCARE);
SHOW(__P);
SHOW(__PRAGMA_REDEFINE_EXTNAME);
SHOW(___errno);
SHOW(__assert);
SHOW(__buf);
SHOW(__filbuf);
SHOW(__flsbuf);
SHOW(__flt_rounds);
SHOW(__fltrounds);
SHOW(__i386);
SHOW(__ia64);
SHOW(__lint);
SHOW(__longlong_t);
SHOW(__posix_asctime_r);
SHOW(__posix_ctime_r);
SHOW(__posix_sigwait);
SHOW(__setp);
SHOW(__sigev_pad2);
SHOW(__signo);
SHOW(__sparc);
SHOW(__strptime_dontzero);
SHOW(__time);
SHOW(__tm);
SHOW(__va_list);
return 0;
}
 
W

Walter Roberson

You are *so* right! Down with the pedants! Just for
the sake of interest, though, would you try the following
program on your system and tell us what the output is?
#define SHOW(x) printf("%s == %d\n", STRING(x), x);

You don't define STRING(x)
 
?

=?ISO-8859-1?Q?=22Nils_O=2E_Sel=E5sdal=22?=

ok said:
I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that names
starting with underscores are reserved for the implementation. I decided not
to because it would make me look like somebody who just wastes other
people's time instead of finding real bugs.
Come on, how serious should we take this rule? This wont ever be an issue
After spending/wasting a day debugging a largish tool that managed to
define
_sys_read, which on one OS clashed with an actual system function which
even the dynamic loader ended up in - failing to load the app, debugger
provided nothing meaningfull etc etc:
Just don't ever do it.

Especially when you know you shouldn't do it.
 
M

MrG{DRGN}

Eric Sosman said:
ok wrote On 03/01/06 13:13,:

You are *so* right! Down with the pedants! Just for
the sake of interest, though, would you try the following
program on your system and tell us what the output is?
-snip code

Won't compile. I get the following "fatal error C1083: Cannot open include
file: 'inttypes.h': No such file or directory."
Is inttypes.h a standard header?
 
A

Al Balmer

-snip code

Won't compile. I get the following "fatal error C1083: Cannot open include
file: 'inttypes.h': No such file or directory."
Is inttypes.h a standard header?

Yes, in C99.
 
R

Richard Heathfield

ok said:
I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that
names starting with underscores are reserved for the implementation. I
decided not to because it would make me look like somebody who just wastes
other people's time instead of finding real bugs.

Please stop wasting other people's time, and go fix the real bug you just
found.
Come on, how serious should we take this rule? This wont ever be an issue

....except when it becomes an issue.

If you stay the hell out of implementation namespace, you eliminate one
possible cause of bugs. Isn't that a good thing?
 
K

Keith Thompson

Richard Heathfield said:
ok said:

Please stop wasting other people's time, and go fix the real bug you just
found.

He said it's in somebody else's code; he may not be in a position to
fix it.

If the code in question is part of the implementation, there's no
problem. If it isn't, using an identifier starting with "__" is
unsafe -- but in practice, it's *probably* only going to be a problem
if the code is used with an implementation that happens to use that
specific identifier.

To the OP: sure, go ahead and notify the author; that would have been
just as easy as notifying the rest of us.
 
V

Vladimir S. Oka

Keith said:
He said it's in somebody else's code; he may not be in a position to
fix it.

If the code in question is part of the implementation, there's no
problem. If it isn't, using an identifier starting with "__" is
unsafe -- but in practice, it's *probably* only going to be a problem
if the code is used with an implementation that happens to use that
specific identifier.

To the OP: sure, go ahead and notify the author; that would have been
just as easy as notifying the rest of us.

Not to mention that it may have fixed or prevented a possibly nasty bug.
 
B

Ben Pfaff

Richard Heathfield said:
If you stay the hell out of implementation namespace, you eliminate one
possible cause of bugs. Isn't that a good thing?

Namespace issues are a problem no matter what you do. I searched
for gc_context (similar to the OP's identifier) online and found
two classes of results: those related to garbage collection in a
Lisp implementation and those related to drawing in a graphics
context. If I wanted to modify the Lisp implementation to
natively support graphics, I could conceivably run into trouble.

However, I agree that starting an identifier with _ is usually a
bad idea. There's a gray area in writing software that you mean
to integrate into a implementation, of course.
 
M

Malcolm

Vladimir S. Oka said:
Not to mention that it may have fixed or prevented a possibly nasty bug.
Not so much a bug as a nuisance.
What will happen is that some compiler will choke on the leading
underscores, but you will be able to coax it into compiling by
specifying --stripped_export or something to the linker. The instructions
for building will gradually become more and more complex until one day the
whole thing refuses to compile at all without getting an expert in that
particular operating system in to set things up.
 
E

Eric Sosman

Walter Roberson wrote On 03/01/06 14:30,:
You don't define STRING(x)

Just trying to make sure it wouldn't compile ...

(I actually ran the awful source through a compiler,
which got so thoroughly bollixed that it never got around
to pointing out my misteak -- the non-intentional one,
that is.)
 
C

CBFalconer

ok said:
I came across some variable name like __gc_context. I started
thinking a bit if I should tell the author of that code that names
starting with underscores are reserved for the implementation. I
decided not to because it would make me look like somebody who
just wastes other people's time instead of finding real bugs.
Come on, how serious should we take this rule? This wont ever be
an issue

Oh yes it will. The implementation needs a namespace to play in,
and using such things can totally foul up your system. A very
likely candidate is __file or _file.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
 
M

Mark McIntyre

Is inttypes.h a standard header?

Yes, but you'll need a recent standards-compliant compiler to provide
it.

7.8 Format conversion of integer types <inttypes.h>
1 The header <inttypes.h> includes the header <stdint.h> and extends
it with additional facilities provided by hosted implementations.
Mark McIntyre
 
O

ok

ok said:
I came across some variable name like __gc_context.
I started thinking a bit if I should tell the author of that code that
names starting with underscores are reserved for the implementation. I
decided not to because it would make me look like somebody who just wastes
other people's time instead of finding real bugs.
Come on, how serious should we take this rule? This wont ever be an issue

I think you all misunderstood me. I know this rule, so its pretty easy to
avoid using them myself.
The question was more is it worth going on a holy crusade and make me look
like a fool who worries too much about C instead of writing software. I did
ask a few coworkers and funnily they all said no I wouldnt tell :)
 
E

Eric Sosman

ok wrote On 03/02/06 12:47,:
I think you all misunderstood me. I know this rule, so its pretty easy to
avoid using them myself.
The question was more is it worth going on a holy crusade and make me look
like a fool who worries too much about C instead of writing software. I did
ask a few coworkers and funnily they all said no I wouldnt tell :)

Let's consider another rule you probably know: Once
you've freed a piece of dynamic memory, it's no longer
yours and you mustn't try to use it. Sound familiar?

All right, then: What would you say if one of your
colleagues wrote a function like this

struct node { struct node *next; ... };
...
void free_linked_list(struct node *head) {
for ( ; head != NULL; head = head->next)
free (head);
}

Even though it's completely illegal, it will "work" on
many systems. If it "works" on all the systems you
happen to be using at the moment, it's not a "real bug,"
right? Would you ask your colleague to change it anyhow?
 
K

Keith Thompson

ok said:
I think you all misunderstood me. I know this rule, so its pretty easy to
avoid using them myself.
The question was more is it worth going on a holy crusade and make me look
like a fool who worries too much about C instead of writing software. I did
ask a few coworkers and funnily they all said no I wouldnt tell :)

Going on a "holy crusade" over this would undoubtedly make you look
like a fool. But I thought you were asking whether you should mention
it to the author of the code. I see no reason not to do so.

You're perfectly willing to engage in a lengthy public discussion of
this issue, as well as discussing it with your coworkers, but you're
agonizing over whether to send a brief e-mail to the author of the
code. It looks like you think there's some strong reason *not* to
inform the author, but I haven't a clue what that reason might be.
What's the problem?
 
C

CBFalconer

Eric said:
.... snip ...

Let's consider another rule you probably know: Once
you've freed a piece of dynamic memory, it's no longer
yours and you mustn't try to use it. Sound familiar?

All right, then: What would you say if one of your
colleagues wrote a function like this

struct node { struct node *next; ... };
...
void free_linked_list(struct node *head) {
for ( ; head != NULL; head = head->next)
free (head);
}

Even though it's completely illegal, it will "work" on
many systems. If it "works" on all the systems you
happen to be using at the moment, it's not a "real bug,"
right? Would you ask your colleague to change it anyhow?

This is very likely to generate a heisenbug. All is well until an
interrupt occurs between executing free and executing "head =
head->next".

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,019
Latest member
RoxannaSta

Latest Threads

Top