Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!brl-tgr!tgr!hadron!jsdy@SEISMO.ARPA
From: jsdy@SEISMO.ARPA
Newsgroups: net.lang.c
Subject: Re:  global declarations
Message-ID: <7073@brl-tgr.ARPA>
Date: Mon, 7-Jan-85 14:11:12 EST
Article-I.D.: brl-tgr.7073
Posted: Mon Jan  7 14:11:12 1985
Date-Received: Tue, 8-Jan-85 05:17:25 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 36

> i have done both of what lauren & yao suggested. have a file called global.h
> which contains:
> 
> 	#ifndef	GLOBAL
> 	#define	GLOBAL	extern
> 	#endif
> 	GLOBAL	int	foo;
> 	GLOBAL	char	bar;
> 
> all files include global.h. from here there are two ways to go about things.
> 1) a file global.c contains:
> 	#define	GLOBAL
> 	#include "global.h"	/* optional */
> 	int	foo = 1;
> 	char	bar;
> ...
> 2) other files just declare a var where they need to, probably only if
>    they desire initialization.

This is almost exactly what I'd rather  n o t  be done.  (Notice, by
the way, that (2) will always conflict with the identical declaration
in (1) if the "extern" storage class is not considered default.)

The C Reference Manual states that a missing storage class defaults
to "extern" outside a function (sec. 8.1, K&R p. 193, last para).
I'd rather leave it at that.  However, many C compilers ignore this.
To be compatible with them, I'd prefer to use an explicit "extern"
in all header (include) files.  Definition and initialisation of a
variable should occur in that module in which that variable is most
used.  (This could be the main module, if the data is (*shudder*)
used everywhere.)  Side benefits:  we don't have to keep travelling
to data.c/global.c to see what something  r e a l l y  is; we may
find that some extern's can become static's; localisation of data
becomes easier; and probably some others.

Joe Yao		(UUCP!seismo!hadron!jsdy / hadron!jsdy@seismo.ARPA)