cgd@netbsd.org (Chris G. Demetriou) writes:

  > Jaromir Dolecek <dolecek@ics.muni.cz> writes:
  >> there is nothing said in 1.3.2's /usr/share/misc/style, so how they
  >> are treated. I'd suppose something like:
  >> 
  >> 1. _foo is used for something internal to code in question - such
  >> as locally used static function

A static function has no scope outside the file in question so you can
use whatever you like, but there seems no point in using a name in a
reserved name space.

  >> 2. __foo is something what is never supposed to show up in usr code
  >> (such as __stat13())

  > No 'normal' user-land code should _ever_ use symbols like those, as
  > far as I'm aware (even for "something internal to code in question").
  > The only things that should are e.g. libc and other 'standard-ish'
  > libraries, and system include files, that need to worry about
  > namespace protection, symbol versioning, etc.

C's namespace rules do not scale very well. If it is "part of the
implimentation" then global symbols should start with '_' except for
symbols explicitly mentioned in the standard.  The problem comes when
you write code which is not part of ISO C but is not "user" code
either ie you would like to extend "the implimentation". If the
symbols only become visible when you include some non standard file or
link some extra library then as far as ISO C is concerned they can
pollute the name space as much as they like, but good practice
dictates otherwise!

Of course if you are extending "the implimentation" then you can use
the namespace reserved for the implimentation, but you take the
responsibility that the extended implimentation is proper (has no
internal clashes, no pollution of the non reserved
space). Unfortunately this doesn't scale very well to multiple
extension efforts.

Ian