Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!apollo!perry
From: perry@apollo.HP.COM (Jim Perry)
Newsgroups: comp.software-eng
Subject: Re: Coding standards (was Re: Programmer productivity)
Message-ID: <474f5cd7.20b6d@apollo.HP.COM>
Date: 8 Dec 89 22:01:00 GMT
References: <1989Dec6.154103.2078@twwells.com> <14850@well.UUCP> <41413@improper.coherent.com>
Sender: root@apollo.HP.COM
Reply-To: perry@apollo.HP.COM (Jim Perry)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 54

In article <41413@improper.coherent.com> dplatt@coherent.com (Dave Platt) writes:
>[in one implementation,]
>All external (global) data variables are, by definition, contained
>within an object module.. and hence within a function.  This isn't
>entirely consistent with the C model, which defines globals as being
>those variables which lie _outside_ of any function.
>
>One way in which a savvy C compiler could resolve this, would be to bundle
>all of the global variables into a dummy module.  Each real module
>(function) in the source-file would access the global variables as if
>they had been declared "extern".  If the linker fetched a function-module
>from the object file, it would "see" that the module was accessing some
>extern variables, would search the "external variables defined" records
>in the object file, and link in the dummy module (which defined the
>globals) as a result.
>
>There's a cost to this approach, though.  It requires that all global
>variables be accessed as "externs", even if they were defined in the
>same source-file as they're being used.  This makes it difficult to
>have "static" variables of file scope... because the very use of the
>"static" keyword requires that the variables' names not be exported
>(for reasons of data-hiding, name-space pollution, etc.)
>
>An effective C compiler can get around this problem by hashing the names
>of the static variables into some horrible string that's guaranteed not
>to collide with any other name.

One scenario based on linkers I've used (which now support C but
didn't when I used them, so this is hypothetical but doable for C):

For every external symbol a module defines (the code of the non-static
functions, and initialized extern variables), a linkage segment is
generated.

File-scope static variables are put in a separate segment, with the
compiled code referencing variables in it as offsets into the segment
(i.e., in C terms, as if all file-scope variables were gathered
together in a single extern struct).  This segment has a name for
linking purposes (all the functions in the file refer to it), but it's
not accessible from the language space.

For every external symbol a function uses, its linkage segment
includes a reference to that symbol.  An external integer reference is
not much different from an external function, as far as linking them
together.  The linker flags multiply-defined symbols, and generates
storage to back uninitialized external variables (referenced but never
defined).  Undefined functions generally are flagged as an error. 
Incidentally, the system I have in mind tags symbol definitions and
references with their datatype, so type conflicts (including function
signatures) are detected.
-
Jim Perry   perry@apollo.hp.com    HP/Apollo, Chelmsford MA
This particularly rapid unintelligible patter 
isn't generally heard and if it is it doesn't matter.