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

[Jay A. Konigsberg]

In article <837 at hls0.hls.oz> george at hls0.hls.oz (George Turczynski) writes:
>In article <13491 at smoke.BRL.MIL>, gwyn at smoke.BRL.MIL (Doug Gwyn) writes:
>> In article <1990Aug4.051827.16438 at nbc1.ge.com> scott at nbc1.GE.COM (Scott Barman) writes:
>> >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. In fact, there are some cases where the only
way to do something is *with* globals - though these situtations are
rare, they do exist. Also, there are times when you want something
to be global to a set of functions. For example the getch() & ungetch()
functions in K&R where the buf[] and bufp vars are shared.

Another case where globals are required involves the use of a signal
catcher() routine. If this routine needs information other than the
signal number, the only way to get it there is via a global (when
invoked by catching the signal that is). The case where I used this
was returning from "raw" to "cooked" char mode. The catcher() routine
had to reset ICANON and a couple of termio.??? values to their original
form.

Accucally, if things like globals and the neferious "goto" were really
_that_ bad, they wouldn't be included in the language. The fact of the
matter is though, sometimes they are needed. Just have good and
supportable reasons for using them.

-- 
-------------------------------------------------------------
Jay @ SAC-UNIX, Sacramento, Ca.   UUCP=...pacbell!sactoh0!jak
If something is worth doing, its worth doing correctly.