WHY doesn't C know anything about directories?

[David Mathog]

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem. For instance, this

int show_current_directory(struct DIRSTRUCT *current_directory);

could return status values like these:

VALID_DIRECTORY
success, and the structure is filled in
PLATFORM_HAS_NO_DIRECTORIES
self evident, what you'd see on an embedded controller, for
instance.
CURRENT_DIRECTORY_DOES_NOT_EXIST
like after "cd /newdirectory", when
the directory has not been created yet. Structure
is filled in. Some bit in that structure indicates
that the directory doesn't actually exist.
ERROR
self evident

The organization of DIRSTRUCT could be platform dependent, so
long as key operations (navigation, create directory, delete
directory, compare directory structures [am I in this directory?]) are
fully supported by functions operating on this type.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Thanks,

David Mathog

 

[Ben Pfaff]

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

Probably because there are perfectly good directory APIs supplied
by standards that build upon C, e.g. SUSv3 and its predecessors.
There's no need to integrate these standards into C.

 

[Chris Hills]

There have been a series of questions about directory operations, all
of which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem.

Because not all file systems are the same.
There are many variants about and already in place.
Any new system would break many of them

 

[David Mathog]

Probably because

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

Thanks,

David Mathog

 

[Clever Monkey]

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem. For instance, this

int show_current_directory(struct DIRSTRUCT *current_directory);

What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

 

[Ben Pfaff]

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

In that case you might consider asking in comp.std.c. That's
where more of the standards committee members hang out.

 

[Alan Curry]

What is a directory? I'm writing a program on a segmented-model
microcontroller that has no host operating system and knows nothing
about things like "files" and "directories".

So your case either proves that the standard C library should not have any
file-related functions, or that there would be no harm in adding
directory-related functions since they would have exactly the same status on
your platform as the file-related functions. Which is it?

Various implementations may add functionality that knows how to talk to
directories, but it was decided this has no place in the core, portable
language.

So you're lobbying to have stdio removed from standard C too, because what's
not supported by your platform has no place in the core?

 

[Richard Heathfield]

David Mathog said:

There have been a series of questions about directory operations, all
of which have been answered with "there is no portable way to do
this".

This raises the perfectly reasonable question, why, in this day and
age, does the C standard have no abstract and portable method for
dealing with directories?

How are you going to deal *portably* with directories on a system that
doesn't have them? Examples include VM/CMS and OS390, both of which are
currently used around the world in the production environments of many
large corporations. These systems /do/ have file organisation methods,
but they ain't directories or anything like.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Because the concept itself is not portable.

 

[Alan Curry]

How are you going to deal *portably* with directories on a system that
doesn't have them?

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

 

[Mark McIntyre]

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

C is designed to be very very portable. As you note, nany platforms on
which C is available have no concept of directories - many have no
concept of disk-based storage at all. So this would all be overhead.

It doesn't seem like a particularly
difficult problem. For instance,

(snip possible way to provide access to directory functionality)

Yes, that'd be possible. The stdio functions probably work much that
way on a platform with no files.

On the other hand, all platforms that support directories /already/
provide facilities to access them. So C would merely be wrapping
existing functionality in a fairly heavy overcoat. If you've ever used
something like Neuron Data, you'll know that providing true
crossplatform facilities can be very expensive and complicated.

And what is 'in' and 'out' was decided by a committee of users,
developers, and vendors. There was presumably no significant demand
from the community to provide a unified directory layer over the top
of the existing structures which everyone was happy with.

So, what's the real scoop. Why doesn't the standard support
portable directory operations????

Essentially because a line had to be drawn somewhere.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Alan Curry said:

The same way you deal with fopen() on a system that doesn't have any
files. By allowing the standardized opendir() to be an
always-return-NULL function on a system that doesn't have anything
matching the directory abstraction.

I fail to see how this gains us anything, since it basically means that
people will be encouraged to write "standard" C programs for hosted
environments which will nevertheless be non-portable to real, serious,
big iron. The *whole point* of a standard is to prevent this. Yes,
embedded systems have some get-outs such as you describe (e.g. not even
having to /provide/ an fopen, let alone returning a null pointer from
one), but this makes writing portable programs *more* difficult, not
less difficult.

 

[Lew Pitcher]

There have been a series of questions about directory operations, all of
which have been answered with "there is no portable way to do this".

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories?

[snip]

Well, you've got a number of answers, most of which I agree with.

I'll add my opinion to the mix, though.

IMHO, the existing definition of the C language already has enough in
it to permit "directory" operations without needing additional
features.

Without violating the semantics of the current C standard, a
hypothetical implementation /could/ provide mechanisms within the
existing stdio definition to permit any sort of directory operations
that you like.

Want to enumerate the files within a directory? This hypothetical
implementation could offer a stream consisting of newline delimited
filenames when a specific filename is read. As in

#include <stdio.h>

{
FILE *directory;

if ((directory = fopen("/some/implementation/defined/path/to/a/
directory/*","r")) != NULL)
{
int byte;

printf("contents of directory:");
while ((byte=fgetc(directory)) != EOF) putc(byte); /* print
file names */
fclose(directory);
}
}

Want to delete a directory?
remove("/some/implementation/defined/path/to/a/directory");

Want to rename a directory
rename("/some/implementation/defined/path/to/a/directory","/some/
other/implementation/defined/path");

Want to change current working directories?
{
FILE *cwd;

if ((cwd = fopen("SYSTEM:current working directory","w") != NULL)
{ fprintf(cwd,"/some/new/path"); fclose(cwd); }

}

And so on.

All you need is an implementation-defined filename string and the
existing standard file functions, and a hypothetical implementation of
a standard C compiler and runtime could offer directory operations /
without violation or extension/ of the existing C standard

Just my two cents worth (1.98 cents US)

 

[Kenneth Brody]

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Clever Monkey]

So your case either proves that the standard C library should not have any
file-related functions, or that there would be no harm in adding
directory-related functions since they would have exactly the same status on
your platform as the file-related functions. Which is it?

Certainly not. My reason is just /one/ of the reasons for "missing"
directory abstractions. See the discussion else thread. There is more
here than a simply dichotomy.

C has a legacy that assumes that a directory is a file, and that basic,
standard abstractions of "FILE" for most systems is Good Enough.
Removing this legacy would be hard to explain. Adding arbitrary stuff
as the language matured is also hard to explain. A line has to be drawn
somewhere, and I'm not sure that implementing a DIR pointer is near that
line.

Given how useless FILE is on some platforms, what form would an even
more complex DIR expression take?

I'm surprised that anyone finds this surprising. One may as well ask
why there are no modern intrinsic string handling routines in C (and
then be shouted down). And yet, it is one of the first things I have to
implement when building any real application or library.

So you're lobbying to have stdio removed from standard C too, because what's
not supported by your platform has no place in the core?

I'm at a loss to explain how you got to what I said to "lobby".

 

[Clever Monkey]

The same way you deal with fopen() on a system that doesn't have any files.
By allowing the standardized opendir() to be an always-return-NULL function
on a system that doesn't have anything matching the directory abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

Indeed. I advise anyone who thinks this is easy to standardize portably
review the history of the Java File and Streams classes, including the
deprecations.

Let it be noted that Java has eschewed the notion of a "directory",
except as a testable instance of File (not unlike a standard IO FILE on
some platforms).

Sun has done a decent job, but it took them a few releases. The
abstract model they came up with does not always work smoothly on all
platforms, and is not the simplest to implement *especially* if you want
any sort of decent performance.

 

[Clever Monkey]

How are you going to deal *portably* with directories on a system that
doesn't have them?
The same way you deal with fopen() on a system that doesn't have any
files.
By allowing the standardized opendir() to be an always-return-NULL
function
on a system that doesn't have anything matching the directory
abstraction.

How would you handle the fact that different systems represent
directory trees differently in filenames? One system may have
something like "/hd1/appl/foobar/data.txt" and another one may
have "disk$1:[appl.foobar]data.txt", and perhaps yet another
may have "data.txt:1".

Indeed. I advise anyone who thinks this is easy to standardize portably
review the history of the Java File and Streams classes, including the
deprecations.

Let it be noted that Java has eschewed the notion of a "directory",
except as a testable instance of File (not unlike a standard IO FILE on
some platforms).

Sun has done a decent job, but it took them a few releases. The
abstract model they came up with does not always work smoothly on all
platforms, and is not the simplest to implement *especially* if you want
any sort of decent performance.

.... and of course Java can push all sorts of portability into highly
system specific VMs, which handle the conversion of a human readable
pathname through an abstract file into a concrete file or directory.

Quoth the Java 1.4.2 Javadocs: "The conversion of a pathname string to
or from an abstract pathname is inherently system-dependent."

That single sentence represents many, many hours of work for me.

 

[Malcolm McLean]

This raises the perfectly reasonable question, why, in this day and age,
does the C standard have no abstract and portable method for
dealing with directories? It doesn't seem like a particularly
difficult problem.

To implement a portable directory libbrary for PCs would be trivial. On
embedded systems you can just return empty lists.

The snag comes with big multi-user systems. A file you list might disappear
in the nanoseconds between call the function and it returning. Then an
enumeration of files might take ten minutes - some directories on our system
have tens of thousands of files, and that is a relatively small biochemical
database.

Whilst it probbaly wouldn't have been impossible to come up with something,
the difficulties were enough to reject the idea.

 

[Christopher Benson-Manica]

Without violating the semantics of the current C standard, a
hypothetical implementation /could/ provide mechanisms within the
existing stdio definition to permit any sort of directory operations
that you like.

While I imagine that the hypothetical implementation you've described
would be conforming, I'm not sure the situation qualifies as a data
point against the idea that the C standard should not specify such
behavior for implementations that choose to handle directory
operations. If a program could be guaranteed that *if* the
implementation provided directory services, they would be provided in
a standard way, a number of new functional possibilities could be
available to implementors.

 

[Christopher Benson-Manica]

I fail to see how this gains us anything, since it basically means that
people will be encouraged to write "standard" C programs for hosted
environments which will nevertheless be non-portable to real, serious,
big iron.

I don't know that the danger would be any more significant than any
number of other non-portable and dangerous assumptions that an
incautious implementor might make. It seems to me to fit in the
"dangerous if misused" category.

 

[Mark McIntyre]

(snip)

Actually I was hoping one of the parties who was actually in on the
decision could tell us. We can all guess but I'd like to know what the
actual reasons were.

Unless someone on the committee corrects him, you may assume that
Ben's answer is not a random guess.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan