underscore names

[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

[Vladimir S. Oka]

ok wrote:

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?

--
BR, Vladimir

You definitely intend to start living sometime soon.

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

[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_REDEFI NE_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_dont zero = __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(__EXTENSIO NS__);
SHOW(__MATHERR_ ERRNO_DONTCARE) ;
SHOW(__P);
SHOW(__PRAGMA_R EDEFINE_EXTNAME );
SHOW(___errno);
SHOW(__assert);
SHOW(__buf);
SHOW(__filbuf);
SHOW(__flsbuf);
SHOW(__flt_roun ds);
SHOW(__fltround s);
SHOW(__i386);
SHOW(__ia64);
SHOW(__lint);
SHOW(__longlong _t);
SHOW(__posix_as ctime_r);
SHOW(__posix_ct ime_r);
SHOW(__posix_si gwait);
SHOW(__setp);
SHOW(__sigev_pa d2);
SHOW(__signo);
SHOW(__sparc);
SHOW(__strptime _dontzero);
SHOW(__time);
SHOW(__tm);
SHOW(__va_list) ;
return 0;
}
--
Er*********@sun .com

[Walter Roberson]

In article <du**********@n ews1brm.Central .Sun.COM>,
Eric Sosman <Er*********@su n.com> wrote:

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)
--
Prototypes are supertypes of their clones. -- maplesoft

[Nils O. Selåsdal]

ok wrote:

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.

[MrG{DRGN}]

"Eric Sosman" <Er*********@su n.com> wrote in message
news:du******** **@news1brm.Cen tral.Sun.COM...

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?

-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?
--
MrG{DRGN}

[Al Balmer]

On Wed, 01 Mar 2006 19:42:12 GMT, "MrG{DRGN}" <Ia****@here.co m> wrote:

"Eric Sosman" <Er*********@su n.com> wrote in message
news:du******* ***@news1brm.Ce ntral.Sun.COM.. .

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?

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

--
Al Balmer
Sun City, AZ

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

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

[Keith Thompson]

Richard Heathfield <in*****@invali d.invalid> writes:

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.

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.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.