identifiers beginning with underscores? 
Author Message
 identifiers beginning with underscores?

Aren't these reserved for use by the compiler in C?  (There used to be a
document online called "Identifiers to Avoid in C Programs," but I can't
find it now.)

The reason I asked is because I recently saw these recommended by a GNU
document
( http://www.*-*-*.com/ ~martin/web/gnome-docu/white-papers/Progra...)
(hate these long URLs) for use as internal non-static identifiers within
libraries.

Cordially,
Steven G. Johnson
--



Fri, 09 Nov 2001 03:00:00 GMT  
 identifiers beginning with underscores?


Quote:
> Aren't these reserved for use by the compiler in C?  (There used to be
a
> document online called "Identifiers to Avoid in C Programs," but I
can't
> find it now.)

> The reason I asked is because I recently saw these recommended by a
GNU
> document

(http://www.edenproject.org/~martin/web/gnome-docu/white-papers/Progra...)

Quote:
> (hate these long URLs) for use as internal non-static identifiers
within
> libraries.

Are you sure this is a GNU document?  From the URL and the header of
the document, it appears to be GNOME Programming Guidelines.

For context, the section of this document with which you have a
problem reads as follows:

+ If you are writing a library, then you may need to have exported
+ symbols that are to be used only within the library.  For example,
+ two of the object files that compose the library libfoo.so may need
+ to access symbols from each other, but this symbols are not meant to
+ be used from user programs. In that case, put an underscore before
+ the function name and make the first words follow the standard
+ module/submodule convention. For example, you could have a function
+ called _foo_internal_frobnicate().

For reference, section 4.1.2.1 the ANSI C standard says the following:

  <snip>
  o All identifiers that begin with an underscore and either an
    uppercase letter of another underscore are reserved for any use.

  o All identifiers that begin with an underscore are always reserved
    as identifiers with file scope in both ordinary identifier and tag
    name spaces.
  <snip>

And, additionally, the GNU Coding Standards say the following:

  Naming Variables and Functions

  Please use underscores to separate words in a name, so that the Emacs
  word commands can be useful within them. Stick to lower case; reserve
  upper case for macros and enum constants, and for name-prefixes that
  follow a uniform convention.

  For example, you should use names like ignore_space_change_flag; don't
  use names like iCantReadThis.

  Variables that indicate whether command-line options have been
  specified should be named after the meaning of the option, not after
  the option-letter.

  A comment should state both the exact meaning of the option and its
  letter.

  For example,

  /* Ignore changes in horizontal whitespace (-b).  */
  int ignore_space_change_flag;

  When you want to define names with constant integer values, use
  enum rather than `#define'. GDB knows about enumeration constants.

  Use file names of 14 characters or less, to avoid creating gratuitous
  problems on System V.

Now, to restate your question:

  What restrictions regarding identifiers beginning with an underscore
  apply to implementors of add-on libraries developed without any
  coordination with the authors of the C implementation with which the
  add-on library is to be used?

IMHO, the gnome people have it wrong here.  The intent of the C standard
seems to me to be that the authors of the C implementation be free to
use all identifiers beginning with underscores with no concern that
those identifiers will collide with identifiers used by either
third-party library authors or by any other authors of code to be built
on/for their implementation.  In particular, the authors of the C
implementation can expect that they can use the identifier
_foo_internal_frobnicate() without fear of collision with an identifier
of this same name used implementors of third-party add-on libraries.

The C standard, at least as I read it, reserves all globally visible
identifiers beginning with an underscore for use by the authors of the
C implementation.  Implementors of a third-party add-on library which
declares a globally visible identifier _foo_internal_frobnicate( would
be in violation of the standard.  By avoiding use of identifiers
beginning with underscores (and, of course, avoiding other speicifically
reserved identifiers), the implementers of a third-party add-on library
can assure that identifiers which they use do not collide with
identifiers used by the authors of the C implementation with which their
library is used.

The C standard, at least as I read it, does not provide any mechanism
by which the implementor of a third-party add-on library can assure that
identifiers used in his library do not collide with identically-named
identifiers used by the implementors of some other third-party add-on
library.

--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
--



Sat, 10 Nov 2001 03:00:00 GMT  
 identifiers beginning with underscores?

   Aren't these reserved for use by the compiler in C?

Yes.

   [...]
   The reason I asked is because I recently saw these recommended by a GNU
   document
   (http://www.edenproject.org/~martin/web/gnome-docu/white-papers/Progra...)
   (hate these long URLs) for use as internal non-static identifiers within
   libraries.

I can see why they chose to make that recommendation; in the GNU
environment and Unix in general it's unlikely to cause problems to use
identifiers of the form _library_function, where library is a library
name and function is a function name, and it helps to discourage
people from trying to use these internal function in program code (as
opposed to internal library code).  It's not good general C practice,
not allowed by the ANSI C standard, but GNOME isn't written in ANSI C,
it's written in non-standard C that will work under Unix.
--



Sat, 10 Nov 2001 03:00:00 GMT  
 identifiers beginning with underscores?

Johnson) wrote in comp.lang.c.moderated:

Quote:
> Aren't these reserved for use by the compiler in C?  (There used to be a
> document online called "Identifiers to Avoid in C Programs," but I can't
> find it now.)

> The reason I asked is because I recently saw these recommended by a GNU
> document
> (http://www.edenproject.org/~martin/web/gnome-docu/white-papers/Progra...)
> (hate these long URLs) for use as internal non-static identifiers within
> libraries.

> Cordially,
> Steven G. Johnson

<Jack>

Symbols beginning with an underscore and an uppercase letter, or two
underscores, are reserved for the implementation in any and all
contexts.

Symbols beginning with an underscore and a lowercase letter are
reserved for the implementation at file scope.

Symbols consisting of a single underscore, or beginning with an
underscore followed by a digit, are not reserved at all.

Local symbols within functions can quite legally begin with an
underscore followed by a lowercase letter.  I'm not sure why anyone
considers it particularly good form to do so offhand.

</Jack>
--
Do not email me with questions about programming.
Post them to the appropriate newsgroup.
Followups to my posts are welcome.
--



Sat, 10 Nov 2001 03:00:00 GMT  
 
 [ 4 post ] 

 Relevant Pages 

1. Problems with functions beginning with underscore (_)

2. Why underscore identifiers?

3. Why underscore identifiers?

4. Underscore Usage In Identifiers

5. underscore

6. replace space by underscore

7. What does the underscore mean/do?

8. underscores in cpp #defines

9. Underscore - should they or should they not?

10. CLS, naming, underscore, and readonly properties

11. Usage of underscores as a prefix

12. Prefixing names with an underscore

 

 
Powered by phpBB® Forum Software