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