Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!unix.cis.pitt.edu!brutus.cs.uiuc.edu!jarthur!aqdata!sullivan
From: sullivan@aqdata.uucp (Michael T. Sullivan)
Newsgroups: comp.std.c
Subject: Re: #include "filename.h" does not mean "include user file"
Message-ID: <1990Mar16.003404.29369@aqdata.uucp>
Date: 16 Mar 90 00:34:04 GMT
References: <6928@cadillac.CAD.MCC.COM>
Organization: aQdata, Inc.  Western Region -- San Dimas, CA
Lines: 21

:From article <6928@cadillac.CAD.MCC.COM>, by ned@pebbles.cad.mcc.com (Ned Nowotny):
> 
> As a result of problems similar to the one described above, it seems that
> programmers should always use the #include <filename> form unless they
> have a specific, well defined situation in which the behavior of the
> #include "filename" form is clearly desired.  The #include "filename" form

I have never thought of "filename" as meaning "an include file in the
current directory".  My usage has been to use <file> when the file is
a Unix supplied header file and to use "file" otherwise.  This gives
future programmers a clue as to where to look for the header file.  Now,
you may have package supplied header files in /usr/include on your system--
that's fine and "file" will still find it but not all systems will have
package-defined header files in /usr/include.  Also, if a future programmer
is porting some code and cpp can't find <file>, then the programmer knows
that the system is lacking a certain header file and that he/she better
get his/her hands on one, instead of wondering why the code came incomplete.
-- 
Michael Sullivan          uunet!jarthur!aqdata!sullivan
aQdata, Inc.              sullivan@aqdata.uucp
San Dimas, CA             +1 714 599 9992