Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!hal!nic.MR.NET!umn-cs!raghavan
From: raghavan@umn-cs.CS.UMN.EDU (Vijay Raghavan)
Newsgroups: comp.lang.c
Subject: Re: Include files
Message-ID: <10995@umn-cs.CS.UMN.EDU>
Date: 28 Jan 89 20:14:22 GMT
References: <10991@umn-cs.CS.UMN.EDU> <9526@smoke.BRL.MIL>
Reply-To: raghavan@umn-cs.cs.umn.edu (Vijay Raghavan)
Organization: CSci Dept., University of Minnesota, Mpls.
Lines: 65

In article <9526@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
<In article <10991@umn-cs.CS.UMN.EDU> raghavan@umn-cs.cs.umn.edu (I) wrote:
<>[...] does the standard
<>condone/permit/require stdio.h (say) to have the following structure: 
<>#ifndef FILE 
<> ...
<>#define FILE struct _iobuf
<> ...
<>#endif !__FILE
<
<Well, more or less.  There are several detailed points involved here.
<
<> If it does, programs like the following should not compile: 
<>main() {
<>#include <stdio.h>
<>FILE *xx;
<>... 
<>}
<>proc1() {
<>#include <stdio.h>
<>FILE *yy;
<>...
<>}
<
<The first point is that the standard headers may be included only
<outside all function bodies (i.e. at file scope level).

   May? Does this mean the same as "are required to"? (Excuse me, but 
that simple English word "may" has always given me trouble. I think it
is because too many people use it as a synonym for "can").

   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.
 
<
<The next point is that a #defined macro's scope extends to the end
<of the translation unit, not just to the end of a block.

I realize this of course. I think you missed the reason why the
program won't compile when the included file has the "#ifndef #endif"
pair surrounding it. It isn't because FILE is
not defined but because struct _iobuf is undefined in proc1().

<
<The third point is that FILE should be a typedef, not a #define.

I'll accept this if you say so (but note that a lot of implementations
seem to think otherwise). However, this makes no difference to the
example I gave. It still won't compile because the lexical scope of the typedef
will still be restricted to the main(){} block.

<
<The final point is that the standard headers may be included more
<than once with no effect different from being included exactly once.
<This is what the "#ifndef FILE" was attempting to accomplish.

I *know* what the "#ifndef FILE" was attempting to accomplish. All I am
saying is that the effect is not the same (as without the "#ifndef") when
the inclusions occur in different mutually non-nesting blocks of the same file.

  Vijay Raghavan