In article <CuxF5B.MHG@ukpsshp1.serigate.philips.nl> baynes@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
>
>#include "stdio.h"
>
>My draft of the standard says that the second should act as the first if the
>compiler can't find the named file in association with the original source
>file. I quote:
>
>    The named source file is searched for in association with the original
>    source file. If this implementation-defined capability is not supported,
>    or if the search fails, the directive is reprocessed as if it read
>
>        # include header-name new-line
>
>    with the identical contained character sequence from the string literal.
>
>This raises an immediate question of is the 'orginal source file' the one
>the compiler originally started compiling or is it the one that contains
>the include directive? The meaning of 'in association' is obviously
>implementation defined - but most compilers take 'in the same directory' as
>part of its meaning.

Except Borland.

I recently tried to compile a file which we can call "foo.c" in a directory
three levels up from where I was.  That file contained:

 #include "foo.h"

and there was a "foo.h" file in the same directory as the foo.c file.
Compiling via:

 bcc -c ..\..\..\foo.c

produced an error message stating that "foo.h" could not be found.

Is Borland the only compiler that fails to do this in the manner to which
I have become accustomed?  (I have yet to find any others which refuse to
even look for the include file in the same directory as the file doing the
including when the double-quoted form of the #include directive is used.)

(Please excuse the fact that this posting has to do with de facto standards,
rather than formal, written standards.  I believe both have relevance to the
practicing programmer.)

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

matt@physics2.berkeley.edu (Matt Austern) writes:

>In article <rfgCvFxwp.852@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

>> Is Borland the only compiler that fails to do this in the manner to which
>> I have become accustomed?  (I have yet to find any others which refuse to
>> even look for the include file in the same directory as the file doing the
>> including when the double-quoted form of the #include directive is used.)

>I think so.  It's the only compiler I've seen, anyway, that behaves
>this way.
>I can't really call it a bug, of course: their compiler works as
>documented, and it is standard-conforming.  I do think Borland's
>behavior is wrong, though, even though it's not quite a bug: it
>behaves in an unexpected manner, and it's much less useful than the
>way that other compilers do things.  It makes life much more difficult
>when you're trying to deal with a project that consists of several
>directories.

I sometimes wish that the C Standard would attempt to cover the concept
of #include file search strategies.   I think I understand why the C
Standard cannot mandate a particular strategy, but I wish it would include
an example of a typical strategy, and then let that influence the
implementations.

In practice, I find that if I use the  #include <file.h> syntax alternative
that I find more uniformity in implementation.   The   #include "file.h"
implementations are more likely to throw me a curve.
--
Larry Weiss, lfw@oc.com
214/888-0471

In article <rfgCvFxwp.852@netcom.com> rfg@netcom.com (Ronald F. Guilmette) writes:

> Is Borland the only compiler that fails to do this in the manner to which
> I have become accustomed?  (I have yet to find any others which refuse to
> even look for the include file in the same directory as the file doing the
> including when the double-quoted form of the #include directive is used.)

I think so.  It's the only compiler I've seen, anyway, that behaves
this way.

I can't really call it a bug, of course: their compiler works as
documented, and it is standard-conforming.  I do think Borland's
behavior is wrong, though, even though it's not quite a bug: it
behaves in an unexpected manner, and it's much less useful than the
way that other compilers do things.  It makes life much more difficult
when you're trying to deal with a project that consists of several
directories.
--

                               --matt

rfg@netcom.com (Ronald F. Guilmette) writes:
|>the include directive? The meaning of 'in association' is obviously
|>implementation defined - but most compilers take 'in the same directory' as
|>part of its meaning.
|
|(Please excuse the fact that this posting has to do with de facto standards,
|rather than formal, written standards.  I believe both have relevance to the
|practicing programmer.)

The original K&R, X/Open, and (from memory) SVID all say "in the same
directory" -- I think X/Open qualifies as a formal, written standard.
Anyway, if Posix doesn't specify this expected behaviour, it should.
ISO C shouldn't, since the concept of "directory" doesn't exist there.
Your C "files" could be data elements in a relational database, etc.
--
David Tanguay       dat@Thinkage.on.ca     dat@Thinkage.com     thinkage!dat
Thinkage, Ltd.           Kitchener, Ontario, Canada          [43.40N 80.47W]