Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: net.lang.c
Subject: Re: Proposal to add modules to C
Message-ID: <5606@utzoo.UUCP>
Date: Fri, 17-May-85 12:59:10 EDT
Article-I.D.: utzoo.5606
Posted: Fri May 17 12:59:10 1985
Date-Received: Fri, 17-May-85 12:59:10 EDT
References: <224@sdcc13.UUCP> <5400006@prism.UUCP>, <5751@umcp-cs.UUCP>
Organization: U of Toronto Zoology
Lines: 18

> It seems to me that the main (if not only) reason to avoid using global
> variables (as opposed to ``module-level'' variables, i.e., accessible
> to foo.c and bar.c but not baz.c) is to avoid name collisions.  If the
> variable makes sense as a statically-allocated unit, why would you care
> whether baz.c can get at it, unless you want to ensure that no accidental
> changes or references are made?

Because I want to ensure that no *deliberate* changes or references are
made!!  That variable is a detail of the *implementation* of the module
in question, and outsiders are not entitled to use it because the
implementation is subject to change.  There are some really ugly places
in Unix where programs *know* details of the implementation of stdio,
for example.  Making things like that globally accessible essentially makes
them part of the specification of the module, hence very hard to change
even if they are later seen as serious mistakes.
-- 
				Henry Spencer @ U of Toronto Zoology
				{allegra,ihnp4,linus,decvax}!utzoo!henry