Get process name w/o using argv[0] in C function?

[BURNS,JIM]

in various articles by (Jay A. Konigsberg),(George Turczynski),(Doug Gwyn),
& (Scott Barman):
>>> >I cannot think of one rational or even irrational reason *not* to use
>>> >global variables.
>>> Really? I thought this was commonly taught in structured software development
>>> courses.
>>Yes, it is, as a principle, to discourage people from using
>>globals and no locals, as they might have gotten used to with
>>such things as BASIC.  It develops the ideas of information
>>hiding and so on.
>>The use of NO globals is however, only adopted by extremists.
> Yes, this is correct.
[Discussion in defense of globals in certain cases.]

 I understood the current emphasis was on not MODIFYING globals in
 subroutines, as this is a side-effect, and can be hard to debug for future
 code maintainers, unless the usage of globals is carefully documented in
 comments sections. It's much cleaner to pass a global as a parameter than
 to let subs modify them (& some say even to access them, since later
 programmers may say "Well, I'm using it anyway - Why can't i modify it?"),
 since it's more obvious you intended for the sub to have access to the
 variable.

 The only time it is critical that subs not reference globals (other than
 system globals such as errno) is in canned library packages, which can't
 1) be dependent on the proper global environment being correctly setup,
 and 2) use global names internally that may collide with global names you
 have defined.

 Of course, the classic text-book example on using globals for information
 hiding is in writing massage routines for a small internal database. All
 you want to do is pass the data/key to be operated on, and the operation
 itself. You do NOT want to pass around the data structures for the database
 itself, so that the massagers will be free to change the implementation
 when database growth demands a reorganization of data or access method.
 (If you pass n arrays as the database in every call to the massage
 routines, you have to track down every one of those calls if the database
 structure changes.) '#include'-ing the appropriate set of global 'extern's
 in only the massage routines hides the database structure from the rest of
 the program.

 And then you have (SysV) Fortran programmers like me that are working on
 parent/child programs (some 78 in my system) where the only efficient
 solution to data sharing is some sort of IPC. I'm defining my COMMON to be
 in shared memory (HP-UX).
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a at prism.gatech.edu