Include path question

[Jan Engelhardt]

Hello,


assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}

-`J'
--

 

[Richard Heathfield]

Jan Engelhardt said:

Hello,


assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

The Standard does not specify the details of interfacing with an
implementation.

 

[Malcolm]

Hello,


assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}

-`J'
--

As a general rule if you include .h files in the same directory as the
associated .c file, they can be include with a simple quoted name.
All compilers have options for specifying default directories to search for
includes, and conventions vary.

 

[Richard Heathfield]

Malcolm said:

All compilers have options for specifying default directories to search
for includes,

Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not stored
in directories.

 

[Malcolm]

Malcolm said:



Some systems don't support the concept of "directory". Compilers on such
systems do not have options for specifying default directories to search
for "includes" (i.e. headers), since headers on such systems are not
stored
in directories.

There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".

 

[Barry]

There are plenty of computer systems without directories, but compilers
don't run on them. The compiler gets so angry at not having a directory to
sit in that it leaves and goes to another machine.
In other words, it becomes a cross compiler.

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".

Wow, I compiled a lot of programs in several languages, naturally C being
one
of them, on an OS that had not concept of directories or folders. And I
assure
you it was not an obscure OS. LOL.

 

[Ancient_Hacker]

Malcolm wrote:

Some systems call directories "folders" for some impenetrable reason. Some
have weird ideas about hierachy. But they certainly have the concept of
"directory".

Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.

But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.

The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.

 

[Malcolm]

Malcolm wrote:




Well I agree that 99.9% of computers out there have OS's with the
concept of "directories". By which you probably mean the ability to
create multiple, named directories. And without the intervention of
the system operator.

But there have been plenty of OS's without that concept. Even OS's for
$12M computers. Most OS's before 1970 or so had either just one
directory for the whole system, or one system directory and one
directory per user, or one directory per physical volume, or
directories had to be created by system staff.

The concept of tree-structured directories didnt get popular until Unix
V6 and MSDOS 2.0 came out.

I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.
However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.

 

[Barry Schwarz]

And others have neither.

I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.

the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories. And it doesn't use a cross compiler. It very
nicely generates native machine code for the S/370, S/390, Z8xx, and
Z9xx families of processors, the same hardware it executes on.

However plenty of embedded systems don't have directories, even though they
may ahve backing store. Everything can be completely flat.

Remove del for email

 

[Gordon Burditt]

The concept of tree-structured directories didnt get popular until Unix

I would say a directory is a group of files which does not include all that
are physically readable by the system.
I don't know of a system with a compiler that doesn't have directories.

CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.

 

[Walter Roberson]

On Sat, 28 Oct 2006 23:27:21 +0100, "Malcolm"

the real world is not bound by the limitations of your knowledge. The
IBM MVS operating system, currently marketed under the name z/OS does
not have directories.

My recollection from <mumble> years ago is that it has logical disks
(not the right term, I know) that are often internally defined as
cylinder groups on physical disks, and that the logical disks can
be associated with a letter, and that a file designation by a user
is by a two part name (the second part of which may be associated
by tradition with a particular file "type") followed by the letter...
e.g., HELLO TEXT Z designating file HELLO TEXT on the cylinder group
currently associated with the letter Z.

Once a letter was associated with a cylinder group, the user could
request a listing of contents, with at least some level of wildcarding.

If the above is still the situation in z/OS then I would say that
z/OS -does- have directories within the definition given by Malcolm --
a grouping of files that does not include all that are physically
readable on the system. There might not be any master directory,
and other than drive A you might have to peak through people's
PROFILE to figure their default file set... and you'd miss all the dynamic
associations...


And it doesn't use a cross compiler. It very

 

[Kenny McCormack]

Wow, I compiled a lot of programs in several languages, naturally C
being one of them, on an OS that had not concept of directories or
folders. And I assure you it was not an obscure OS. LOL.

MSDOS 1.0?

 

[Kenny McCormack]

I would say a directory is a group of files which does not include all
that are physically readable by the system. I don't know of a system
with a compiler that doesn't have directories. However plenty of
embedded systems don't have directories, even though they may ahve
backing store. Everything can be completely flat.

The point is that none of that matters. The C standard doesn't require
it, so, as far as the troglodytes in this ng are concerned, it doesn't
exist.

 

[Richard Heathfield]

Malcolm said:

There are plenty of computer systems without directories, but compilers
don't run on them.

MVS and VM/CMS are counter-examples. Undoubtedly there are others as well,
but those will suffice. Both are platforms for which ISO C implementations
exist, and neither has the concept of "directory".

 

[Jean-Marc Bourguet]

Hello,


assume foo/bar.h exists, and is included as '#include "bar.h"' in
foo/bar.c. `gcc -c foo/bar.c` will compile it fine (i.e. finds the
file). Is this a gcc extension or a C compiler standard feature that
foo/ will be searched without explicitly passing -Ifoo?

$ cat foo/bar.h
#define GOAL 1

$ cat foo/bar.c
#include <stdio.h>
#include "bar.h"
int main(void) {
printf("%d\n", GOAL);
return 0;
}

I've collected the behaviour of some C and C++ compilers on
http://www.bourguet.org/cpp/include.html
If you know other behaviours, I'm interested to add them.

Yours,

 

[CBFalconer]

Malcolm said:
.... snip ...

MVS and VM/CMS are counter-examples. Undoubtedly there are others
as well, but those will suffice. Both are platforms for which ISO
C implementations exist, and neither has the concept of "directory".

Another one, easily available to most, is CP/M-80. An easily
available simulator for many systems is at:

<http://www.schorn.ch/cpm/intro.html>

 

[Barry Schwarz]

My recollection from <mumble> years ago is that it has logical disks
(not the right term, I know) that are often internally defined as
cylinder groups on physical disks, and that the logical disks can
be associated with a letter, and that a file designation by a user
is by a two part name (the second part of which may be associated
by tradition with a particular file "type") followed by the letter...
e.g., HELLO TEXT Z designating file HELLO TEXT on the cylinder group
currently associated with the letter Z.

Once a letter was associated with a cylinder group, the user could
request a listing of contents, with at least some level of wildcarding.

If the above is still the situation in z/OS then I would say that
z/OS -does- have directories within the definition given by Malcolm --
a grouping of files that does not include all that are physically
readable on the system. There might not be any master directory,
and other than drive A you might have to peak through people's
PROFILE to figure their default file set... and you'd miss all the dynamic
associations...

Sorry but MVS has never had an association between a "logical disk"
and a letter. IBM has several different operation systems and a
different one may have something similar to what you describe.


Remove del for email

 

[Leor Zolman]

CP/M 2.0 would qualify as not having directories, with the BDS C
Compiler. It wasn't ANSI C compliant (what was in the late 1970's?
Although this one didn't support floating point, at least the early
versions didn't). Unless you decided that each floppy had its
own directory and that constituted directory support, it didn't
support directories.

Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas. For the capacities of the day
(I paid $3,600 for a 10mb 8" Morrow hard disk drive circa 1980...), 16
subdirectories were plenty...
-leor

 

[Jan Engelhardt]

I've collected the behaviour of some C and C++ compilers on
http://www.bourguet.org/cpp/include.html
If you know other behaviours, I'm interested to add them.

GCC should be put into the list where Visual C is listed, because that
is what I observed (#include "" in the directory of the file containing
the directive).

Have you tried SUNWspro yet?

-`J'
--

 

[Gordon Burditt]

The concept of tree-structured directories didnt get popular until Unix

Can't recall if they were there in CP/M 2.0 or were only introduced for
2.2, but there were "user areas" that subdivided a logical drive into,
I believe it was, 16 numbered sub-areas.

I'm reasonably sure they weren't present in CP/M 2.0, which is why
I said CP/M 2.0. The "sub-areas" didn't increase the number of
files you could fit on a floppy. "user 0" was special. A "user
0" file appeared in all "sub-areas", and a program running as "user
0" saw only "user 0" files.

And perhaps most important, there was no standardized way of
specifying "the config.h file in user area 5" by some kind of path
name. CP/M didn't provide a way of translating a text "path name"
into a FCB, so although it was possible to invent a syntax for such
a "path name", every application that wanted to use such a thing
had to be aware of the syntax or use a library that was, and it
wouldn't work for applications written before that feature was
introduced.