Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!rpi!uupsi!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: A question on C programming style
Message-ID: <15824@smoke.brl.mil>
Date: 15 Apr 91 21:05:44 GMT
References: <1991Apr12.103621.8907@umiami.ir.miami.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 22

In article <1991Apr12.103621.8907@umiami.ir.miami.edu> devebw9f@miavax.ir.miami.edu writes:
>foo.h
>  #include <stdio.h>
>use.c
>  #include "foo.h"
>  #include <stdio.h>

Unless you're sure you will never be porting to a non-ANSI C environment,
I recommend against this, since in general you cannot be sure that the
standard headers can be safely included multiple times in the same
translation unit.  (I have had trouble with this in actual practice.)

For headers that you supply yourself, so long as you arrange proper
idempotency locks in the headers, nested inclusion should be fairly
safe.  Be aware, however, that applications need to know what ranges
of identifiers will be usurped by inclusion of any header, and when
nested inclusion is used, the name space usurption is larger than may
at first be apparent.  If you follow some strict naming scheme such
as the "package prefix" approach that I have described here previously,
this should not be a large problem.  If, on the other hand, you don't
control what names are used in the headers, it makes application
programming more difficult than it need be.