strings.h

[Karl Denninger]

In article <1990Feb12.140349.10280 at antel.uucp> mike at antel.uucp (Michael Borza) writes:
>In article <1990Feb9.185219.11046 at ddsw1.MCS.COM> karl at mcs.MCS.COM (Karl Denninger) writes:
>>In article <8 at robecdc.UUCP> ghost at robecdc.UUCP (William.A.Sneed) writes:
>>>In article <1762 at milton.acs.washington.edu> milton at 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 at 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"