Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!decwrl!labrea!csli!gandalf
From: gandalf@csli.STANFORD.EDU (Juergen Wagner)
Newsgroups: comp.lang.c
Subject: Re: Include files
Message-ID: <7360@csli.STANFORD.EDU>
Date: 30 Jan 89 02:36:40 GMT
References: <10991@umn-cs.CS.UMN.EDU> <9526@smoke.BRL.MIL> <10995@umn-cs.CS.UMN.EDU>
Reply-To: gandalf@csli.stanford.edu (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 46

In article <10995@umn-cs.CS.UMN.EDU> raghavan@umn-cs.cs.umn.edu (Vijay Raghavan) writes:
>...
>   My question was simple: Should a program like
>the above give compilation errors? I don't necessarily adopt that style
>of including the same header file in two different functions in the same
>source file; I found it in a Path Pascal compiler I was porting to a Sun
>environment. (Actually, the included file was "stat.h" but the point is 
>the same). Treat it as a question of academic interest only, if you like.

Hmmm... you found that in a PASCAL compiler? Well, then the point is not the
same because PASCAL allows you to restrict the scope of a function/variable
to a function's/procedure's lexical scope. In C, there is no such concept
except the idea of local variables (unless you split your file into multiple
files, one top-level function per file, others static).

With that in mind, I would still say that it doesn't seem to be meaningful
to include standard header files more than once (remember: e.g. typedefs
must not be included more than once). Note the word "standard". Somebody
pointed me to the winner of the last Obfuscated C Contest. This program
apparently used multiple header file inclusion deliberately to get some
weird recursive effect.

Coming back to the original point, I think, you can get dangerous effects
from a number of sources:

o  If the header file defines a struct, your optimizer may decide to optimize
   the structs in different ways for the two functions. Exchanging data won't
   work then (e.g. one function writes the struct to a file, the other reads
   it. Parameter passing is out since the struct isn't defined globally).

o  #define macros will have to be #undef'ed before every definition to avoid
   nasty messages from cpp. You won't be able to distinguish accidental
   redefinitions from intended redefinitions otherwise.

o  If you look at standard header files like <dbm.h>, there are lines
	char    pagbuf[PBLKSIZ];
	char    dirbuf[DBLKSIZ];
   i.e. variable declarations. If you include the header file twice (and
   function-local), you will end up with two copies of the (supposedly)
   shared state variables.

I guess, what you want is some kind of PASCAL-like scoping for C...

-- 
Juergen Wagner		   			gandalf@csli.stanford.edu
						 wagner@arisia.xerox.com