Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!charyb!will
From: will@charyb.COM (Will Crowder)
Newsgroups: comp.lang.c
Subject: Re: Extern variables question
Message-ID: <316@charyb.COM>
Date: 17 Nov 89 19:12:24 GMT
References: <1958@atanasoff.cs.iastate.edu> <89320.012957CMH117@PSUVM.BITNET> <312@charyb.COM>
Reply-To: will@charyb.UUCP (Will Crowder)
Distribution: na
Organization: KFW Corporation, Newbury Park, CA
Lines: 38

In article <312@charyb.COM> dan@charyb.UUCP (Dan Mick) writes:

>In article <89320.012957CMH117@PSUVM.BITNET> CMH117@PSUVM.BITNET (Charles Hannum) writes:
>>
>>[comment about defining global data in only one module, and declaring
>> it in the other modules used]
>
>Again:  What?
>
>Most PC linkers I've used will; but not Microsoft's, at least not with C 
>5.1, and *no* Unix linker I've ever heard of does.  That seems, to me, to
>be one of the huge implementation-philosophy differences between Unix-oid
>C and PC-oid C.
>-- 
>.sig files are idiotic and wasteful.

Why the "What?", Dan?  The man's answer was good advice as far as I'm
concerned.  I prefer the PC-oid style.  It just seems to make sense that 
since you're defining storage for one location, you define it in one place.  
You can declare its existence wherever you want to use it.  This actually 
seems useful to me, since that way you can know that once you've found the 
definition of the variable you aren't using, you can remove it *in once 
place* and it's gone.  Other modules which used it will get complaints.  
Further, the PC-oid style encourages the concept of an object module 
"owning" a data object.  If indeed it is not appropriate for any single 
executable code module to own the data object, because it's used equally 
everywhere, then you can have a "global data" module which only defines 
the global data.  Again, the scope and ownership of the data object
is defined in the source module.

Also, the PC-oid style encourages (read: requires) differentiation between 
the definition of an object (which reserves space), and the declaration 
of an object (which does not).  I consider this useful: one object,
one definition, multiple declarations of its existence in other source
modules which use it, and might depend on its proper initialization,
and which will cause complaints if the object doesn't exist at linktime.

Will