Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!agate!labrea!csli!gandalf
From: gandalf@csli.STANFORD.EDU (Juergen Wagner)
Newsgroups: comp.lang.c
Subject: Re: Include files
Message-ID: <7338@csli.STANFORD.EDU>
Date: 28 Jan 89 03:08:11 GMT
References: <10991@umn-cs.CS.UMN.EDU>
Reply-To: gandalf@csli.stanford.du (Juergen Wagner)
Organization: Center for the Study of Language and Information, Stanford U.
Lines: 34

Vijay Raghavan (raghavan@umn-cs.cs.umn.edu) writes:
> Is the Sun style of surrounding the text of standard "include" files 

I am not sure that's "Sun" style. It is just a way of preventing a header
file from being included twice because you'll never know who else includes
that particular file.

>with a #ifndef-#endif pair really okay? Specifically, does the standard
>condone/permit/require stdio.h (say) to have the following structure: 

Why should the standard require/forbid such files? There is a rationale for
having them: Header files as found in /usr/include/... are supposed to contain
global definitions and declarations, i.e. items which are typically included
at the beginning of a module (not a function). Having things like stdio local
to a function sounds a little strange, in particular because <stdio.h> on
e.g. Suns says something like
	extern  struct  _iobuf {...}
and a number of #defines, i.e. global declarations and definitions.
Redefinition of these concepts isn't necessary/is treated as an error.

> If it does, programs like the following should not compile: 
>...

Why would one want to use such a program structure as opposed to having a
single inclusion of <stdio.h>? I thought about it but couldn't come up with
an answer.

There certainly are other cases where multiple inclusion is meaningful. Yet,
I would claim that in most of these cases, a single inclusion which defines
an appropriate macro would be sufficient. I can be convinced of the opposite!

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