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

[Kenneth Brody]

David Mathog wrote:

>
user923005 wrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure. It would be nice if the language supported
these machines.

[...]

Just because every computer that _you_ work with has a directory
structure, doesn't mean that all computers do. Plus, those that
do have directory structures don't all have the same kind of
structure, as noted elsethread. (For the record, every computer
that I currently program in C on has a directory structure, and
they all have a similar way of representing directory paths.
However, I have coded in C on a system with a very different
method of representing directories. We don't support that
platform anymore, though there is still conditional code in some
of the modules to handle this difference.)

Also, just because the C language standard doesn't support such a
construct doesn't mean that other standards which do support them
can't be used. Most of the systems I work on have support for a
set of calls with names like opendir(), readdir(), closedir(), and
so on, which seem to be pretty standardized, though I don't see
any reference to a formal standard.

Perhaps POSIX has such support?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Chris Hills]

In article <46*****************@news.xs4all.nl>, Richard Bos
<rl*@hoekstra-uitgeverij.nlwrites

>David Mathog <ma****@caltech.eduwrote:

>user923005 wrote:

Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

A. Every computer I work with (locally numbering into the hundreds)
has a directory structure. It would be nice if the language supported
these machines.

Every computer I work with has a graphics screen. It would be nice if
the language supported these machines. But it doesn't, and there are
very good reasons for that.

Every computer I work with has 30mm automatic cannon attached to it.....
.... And a screen but no file system :-)

there are many thousands of different systems that use C. the core
language covers them. We do not need every variation added to the core.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Walter Roberson]

In article <46***************@spamcop.net>,
Kenneth Brody <ke******@spamcop.netwrote:

>Also, just because the C language standard doesn't support such a
construct doesn't mean that other standards which do support them
can't be used. Most of the systems I work on have support for a
set of calls with names like opendir(), readdir(), closedir(), and
so on, which seem to be pretty standardized, though I don't see
any reference to a formal standard.

>Perhaps POSIX has such support?

[OT]
Yes, ISO/IEC 9945-1 (IEEE Std 1003.1, aka POSIX.1 from 1990).

It leaves as implementation defined whether a leading // has
special meaning (basically, it's allowed as an escape into
other kinds of filesystems or network filesystems). It also
does not define much beyond the standard user/group/other permissions;
the attempt later to standardize access control lists was dropped
(and the authors of that draft now consider standardized ACLs a dead topic.)

--
I was very young in those days, but I was also rather dim.
-- Christopher Priest

[David Mathog]

Ian Collins wrote:

David Mathog wrote:

>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".

More of an aside, but you might be interested in the design decisions
behind the proposed C++ filesystem library:

http://www.boost.org/libs/filesystem...al.html#Design

That was interesting. Especially the part about OpenMVS being an HP
trademark ;-).

Regards,

David Mathog

[David Mathog]

Flash Gordon wrote:

Richard Bos wrote, On 08/06/07 08:31:

<snip>

>With directories, however, matters are a little more complicated. Even
on systems where you have directories and you can navigate them, there
is no simple way to specify _how_ to navigate them completely and
reliably that works on all systems. If you think that "go to top of
directory tree; list all files; find first sub-directory; recurse; find
next subdirectory; re-recurse" suffices and will do the job on all
systems out there, you simply haven't had much experience of many OSes.
Hell, you probably haven't even considered how you handle Windows drive
letters...

A psuedo-directory one level up that has the drives as simple letters...

Ditto for VMS.

Regards,

David Mathog

[David Mathog]

Chris Hills wrote:

>
there are many thousands of different systems that use C. the core
language covers them. We do not need every variation added to the core.

Actually I agree, but I diverge on the way it is "not covered". The
current method seems to be to leave out any functionality which
is not universal, whereas I think it would be better for the language to
include highly common, but not universal, functionality, but supply test
functions more or less like this:

#include <stddir.h>
#include <stdgraphics.h>

/* compile time checking */
#ifdef STDDIR_SUPPORT
#ifdef STDGRAPHICS_SUPPORT
#endif
#endif

/* or run time checking */

if(directory_support(){
if(graphics_support()){
}
}
else {
}

How much work are we talking about for compilers on systems that don't
offer this support? Seems like practically none. Here's part of
stddir.h for such a system:

/* sttdir.h - disable all directory options portably on this system */
#ifndef _STDDIR_H
#define _STDDIR_H
#define STDDIR_SUPPORT 0
typedef struct is_dirstruct DIRSTRUCT;
struct is_dirstruct{ int notsupported; };
/* prototypes */
int directory_support(void);
DISTRUCT *directory_create_direstruct(void);int
directory_otherfunction(DIRSTRUCT *arg1, char *arg2);
/* etc. */

/* actual functions */
int directory_support(void){ return 0; }
DISTRUCT *directory_create_direstruct(return NULL);
int directory_otherfunction(DIRSTRUCT *arg1, char *arg2){ return 0; }
/* etc. */

#endif /* stddir.h */

The language standard itself could easily define this include file for
compilers

Should graphics also be part of the language? That's in some ways a
more interesting question than for directory operations, because
there are so many different ways it could be done. I'm thinking no
though, because right now one can already choose a cross platform
graphics library and work with that. Also graphics is vastly more
complex than directory or database models of file organization.

Regards,

David Mathog

[¬a\\/b]

On Wed, 06 Jun 2007 11:14:30 -0700, <dcorbit@wrote:

>Directory structures are antiquated loads of crap.

We should put everything into a database (including making the file
system be a database).

For file systems, a network model or hierarchy is probably better than
a relational model.

At any rate, the C language itself is the wrong place to reform
things.

IMO-YMMV.

the operations "read or write" to directory or files are all the same

all that is not there are standard functions that donig above
operations

[Szabolcs Nagy]

David Mathog wrote:

Should graphics also be part of the language? That's in some ways a
more interesting question than for directory operations, because
there are so many different ways it could be done. I'm thinking no

now that's where you completely wrong sir

there are so many different ways directories could be done (different
concepts, different performance charasteristics for different kinds of
access, etc)
and --as it was mentioned earlier-- system specific solutions will
always beat the extremely narrow special use case of the standard

i don't understand how can you still insist on this with so many
helpful answers on the topic

it's like you would want to standardize mouse input events and if
someone has a different input device then he'll just suffer a little
performance loss or return ENOT_IMPLEMENTED

[Chris Hills]

In article <f4**********@naig.caltech.edu>, David Mathog
<ma****@caltech.eduwrites

>Chris Hills wrote:

> there are many thousands of different systems that use C. the core
language covers them. We do not need every variation added to the core.

Actually I agree, but I diverge on the way it is "not covered". The
current method seems to be to leave out any functionality which
is not universal, whereas I think it would be better for the language
to include highly common, but not universal, functionality,

File systems are not "highly common". They may be in your field but
not in a large number of others. Also there are many different types of
file system. The most common one is not on a PC... smart cards have a
very different file system... Most people have more smart cards than
PC's

but supply test functions more or less like this:

#include <stddir.h>
#include <stdgraphics.h>

/* compile time checking */
#ifdef STDDIR_SUPPORT
#ifdef STDGRAPHICS_SUPPORT
#endif
#endif

/* or run time checking */

if(directory_support(){
if(graphics_support()){
}
}
else {
}

How much work are we talking about for compilers on systems that don't
offer this support? Seems like practically none.

Most compilers will support ifdef BUT

We have been round this loop before for graphics. (Several times)

There are many very good graphics systems out there for all manner of
things. From instrument panel type libraries to various GUIs other than
the ones with Windows, Solaris, 3(?) for Linux, MAC, etc etc

So will your new "standard" graphics incorporate these or be different?
Likewise for file systems (NOT "directory structures" )

At the moment all bar about 5 compilers do not have full C99 compliance
and are never likely to. Their markets do not require or ask for it. If
you add Graphics, file systems etc the net result is 95% of the most
common compilers on the market will ignore it. .

>Should graphics also be part of the language? That's in some ways a
more interesting question than for directory operations, because
there are so many different ways it could be done. I'm thinking no
though, because right now one can already choose a cross platform
graphics library and work with that. Also graphics is vastly more
complex than directory or database models of file organization.

There are cross platform graphics libraries out there now. Your
standard will have to incorporate al of them or it will be ignored. If
it incorporates al of them it is pointless
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Mark McIntyre]

On Thu, 07 Jun 2007 15:40:50 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>Mark McIntyre wrote:

>On Thu, 07 Jun 2007 08:30:41 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>>It would be nice if the language supported
these machines.

No need, since platform-specific extensions do it very well.

There is a need because it's a PITA to port those platform specific
extensions to another set of platform specific extensions.

I'm one of the few people I know who has experienced the fun of
porting from (64-bit) VMS to (32-bit) Unix and (16-bit) DOS. Believe
me, porting directory support was the /least/ of my issues.

A well designed app will be immune to such vagaries anyway - for
instance paths to data, config files, etc etc should be externalised.

>I don't think you understand how a database filesystem works. Consider
an ordinary RDBMS. A row isn't 'down' from a table, and a row in a
different table isn't 'across'. if you select * from table where
filetype=bla and filedescription like gibble you don't get some sort
of hierarchical tree returned.

UP ACROSS and DOWN define navigation on a grid on a 2D surface,

Databases don't have 2d surfaces.

>database can be mapped so that every file it contains lies on
that 2D surface

Yes, but they can't. The whole point is that its a /relational/
database, with multiple keys cutting any-which-way over your data.

>In your example we need to get to all files "in":
some table, filetype=bla, filedescription=gibble.

Start at the database "TOP" (nothing selected)

Navigate DOWN: Lists all tables, from list select a table.
Navigate DOWN: List all columns in table, from list select "fileteype".
Navigate DOWN: List all values in column, from list select "bla".

And this is efficient how exactly ? Compared to a single,
well-optimised select ?

This is the crux: /some/ OSen offer simple hierarchical directory
trees, not really searchable except on crude criteria. Even so, these
differ significantly in how data is addressed. Consider that unix
stores one version of each file, while VMS stores as many as you like.
Some OSen offer significantly more complex multidimensional storage,
which are fully searchable. Basic operations like "list all files in
this directory" are meaningless in these OSen.

>My point still being, that with C modified this way the program
just sees standard function calls for navigating UP and DOWN

And you end up either with hideously inefficient functions, which are
be very inflexible, or with hideously complicated functions with
zillions of parameters and bitfields filled with flags, all required
in order to get it to be efficient and/or operate with your particular
OS. Witness the cack that goes into the Windows APIs, all in order to
provide compatiblity with a half-dozen slightly different versions of
the same OS.

--
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

[Mark McIntyre]

On Fri, 08 Jun 2007 12:49:52 -0700, in comp.lang.c , David Mathog
<ma****@caltech.eduwrote:

>Flash Gordon wrote:

>Richard Bos wrote, On 08/06/07 08:31:

<snip>

>>With directories, however, matters are a little more complicated. Even
on systems where you have directories and you can navigate them, there
is no simple way to specify _how_ to navigate them completely and
reliably that works on all systems. If you think that "go to top of
directory tree; list all files; find first sub-directory; recurse; find
next subdirectory; re-recurse" suffices and will do the job on all
systems out there, you simply haven't had much experience of many OSes.
Hell, you probably haven't even considered how you handle Windows drive
letters...

A psuedo-directory one level up that has the drives as simple letters...

Ditto for VMS.

although sys$system: is hardly a simple letter.

--
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

[David Thompson]

On Tue, 05 Jun 2007 12:25:06 -0700, Lew Pitcher
<lp******@teksavvy.comwrote:
<snip>

IMHO, the existing definition of the C language already has enough in
it to permit "directory" operations without needing additional
features. <snip>
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. <snip>

Not if a filename can include a newline character -- as is legal on
Unix, though in every case I've seen it used a supremely bad idea.
(Backspace, or (bare) carriage-return, is usually even worse.)

And if a filename can include a null character -- which Unix cannot,
but ISTR something else maybe MacClassic can -- then the 'obvious' way
of using fgets() won't work right. (Although of course improvements on
fgets() are ontopic here and indeed quite frequently discussed.)

It would work to make it newline-delimited _prettified_ (e.g. escaped)
filenames, if fopen() et al handle the same, AND either users already
understand them, or users are trained to understand them, or we also
have (and standardize?) some user-interface aids for them.

But by this point it's no longer so trivial.

- formerly david.thompson1 || achar(64) || worldnet.att.net

[Richard Tobin]

In article <96********************************@4ax.com>,
David Thompson <da************@verizon.netwrote:

>And if a filename can include a null character -- which Unix cannot,
but ISTR something else maybe MacClassic can -- then the 'obvious' way
of using fgets() won't work right.

If a filename can contain a nul, fopen() isn't going to work on it.
If the implementation hasn't solved the problem for fopen() (e.g. by
some escaping mechanism), it probably doesn't make things much worse
if it omits the file from the directory listing.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Dik T. Winter]

In article <96********************************@4ax.comDavid Thompson <da************@verizon.netwrites:

On Tue, 05 Jun 2007 12:25:06 -0700, Lew Pitcher
<lp******@teksavvy.comwrote:
<snip>

IMHO, the existing definition of the C language already has enough in
it to permit "directory" operations without needing additional
features. <snip>
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. <snip>

Not if a filename can include a newline character -- as is legal on
Unix, though in every case I've seen it used a supremely bad idea.
(Backspace, or (bare) carriage-return, is usually even worse.)

Oh, well, that has been solved, back when somebody within a Unixy
environment thought of null-delimited lists of filenames. Now what
*is* a bad idea is a carriage-return in your password for Unix, but
that's another story.

And if a filename can include a null character -- which Unix cannot,
but ISTR something else maybe MacClassic can -- then the 'obvious' way
of using fgets() won't work right. (Although of course improvements on
fgets() are ontopic here and indeed quite frequently discussed.)

MacOS also not, as far as I know, in any of its incarnations. But if
an OS allows null characters into its filenames, it better also includes
some translation mechanism from C strings to filenames, vv. That is not
so very difficult.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, [phone]
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/