Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!usenet.ins.cwru.edu!mephisto!rutgers!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.xenix
Subject: Re: strings.h
Summary: However, " " will search both areas
Message-ID: <1990Feb14.191354.6339@ddsw1.MCS.COM>
Date: 14 Feb 90 19:13:54 GMT
References: <7472@tank.uchicago.edu> <1762@milton.acs.washington.edu> <8@robecdc.UUCP> <1990Feb9.185219.11046@ddsw1.MCS.COM> <1990Feb12.140349.10280@antel.uucp>
Reply-To: karl@mcs.MCS.COM (Karl Denninger)
Organization: Macro Computer Solutions, Inc. - Mundelein, IL
Lines: 65

In article <1990Feb12.140349.10280@antel.uucp> mike@antel.uucp (Michael Borza) writes:
>In article <1990Feb9.185219.11046@ddsw1.MCS.COM> karl@mcs.MCS.COM (Karl Denninger) writes:
>>In article <8@robecdc.UUCP> ghost@robecdc.UUCP (William.A.Sneed) writes:
>>>In article <1762@milton.acs.washington.edu> milton@milton.acs.washington.edu (Stephen Milton) writes:
>>>>I keep running into the same error...'cannot find strings.h'  It 
>>>	If your program has #include "strings.h" that's your problem
>>
>>No, that is not the problem.
>>
>>>	Should be <strings.h> to use the system's library
>>
>>Actually either will work -- if the file is there.

For system library files, this is a true statement.

>>There is no difference between the delimiters.  Try it sometime.  CONVENTION 
>>is that you use " " as delimiters on local include files, and < > on system
>>files, but the compiler will search in both places with either delimiter.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This part has proven to be false and worked here due to the way we tend to
group ".h" files and specify their locations (by passing a "-I" switch)

>Well, actually, the delimiters " " and < > may work the same on your
>particular system, but that is not the correct behaviour in K&R C,
>and probably not in ANSI C either.  Double qoute delimiters cause the
>preprocessor to prepend the current directory to the search path for
>include files.  Angle bracket delimiters cause only the "standard"
>directories to be searched, usualy /usr/include on UNIX systems.

Unless you have a "-I" directive on the compiler call, which we did (oops)
:-)

>This means that a file strings.h in the current directory will be found
>if a preprocessor directive
>	#include "strings.h"
>is in a given source file.  It will not be found if the directive
>	#include <strings.h>
>is issued and strings.h does not exist in the system include path.

Ah, but 

#include	"strings.h"

WILL find the file in /usr/include as well as your current directory.

>I was surprised enough by your assertion to try it here, under ISC
>386/ix using AT&T's PCC compiler.  As expected, " " and < > *do not*
>behave the same and *do* exhibit their correct, documented, and expected
>behaviour.  If file inclusion does not work this way on your system,
>your compiler is broken.

No, my example was broken.  I was half-right.  The assertion about 

#include "file.h"

looking in system library space still holds (and I just checked it again to
make sure I wasn't full of it).

Thus, in this particular quoted case, it wouldn't matter.

--
Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
Public Access Data Line: [+1 708 566-8911], Voice: [+1 708 566-8910]
Macro Computer Solutions, Inc.		"Quality Solutions at a Fair Price"