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)