strings.h
Michael Borza
mike at antel.uucp
Tue Feb 13 01:03:49 AEST 1990
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.
>
>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.
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.
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.
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.
>Karl Denninger (karl at ddsw1.MCS.COM, <well-connected>!ddsw1!karl)
mike borza.
--
Michael Borza Antel Optronics Inc.
(416)335-5507 3325B Mainway, Burlington, Ont., Canada L7M 1A6
work: mike at antel.UUCP or uunet!utai!utgpu!maccs!antel!mike
home: mike at boopsy.UUCP or uunet!utai!utgpu!maccs!boopsy!mike
More information about the Comp.unix.xenix
mailing list