Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!samsung!sdd.hp.com!ucsd!pacbell.com!pacbell!sactoh0!jak
From: jak@sactoh0.UUCP (Jay A. Konigsberg)
Newsgroups: comp.unix.questions
Subject: Re: Get process name w/o using argv[0] in C function?
Message-ID: <3682@sactoh0.UUCP>
Date: 10 Aug 90 12:02:34 GMT
References: <9220003@hpldsla.sid.hp.com> <1990Aug4.051827.16438@nbc1.ge.com> <13491@smoke.BRL.MIL> <837@hls0.hls.oz>
Reply-To: jak@sactoh0.UUCP (Jay A. Konigsberg)
Organization: SAC-UNIX, Sacramento, Ca.
Lines: 40

In article <837@hls0.hls.oz> george@hls0.hls.oz (George Turczynski) writes:
>In article <13491@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>> In article <1990Aug4.051827.16438@nbc1.ge.com> scott@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.