Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

C Programming Language

WHY doesn't C know anything about directories?


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

David Mathog <mat@caltech.edu> writes:
> 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.
--
Ben Pfaff
http://benpfaff.org
In article <f44173$nl@naig.caltech.edu>, David Mathog
<mat@caltech.edu> writes

>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

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ c@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Ben Pfaff wrote:
> David Mathog <mat@caltech.edu> writes:

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

(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

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

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

David Mathog <mat@caltech.edu> writes:
> Ben Pfaff wrote:
>> David Mathog <mat@caltech.edu> writes:

>>> 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
> (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.
--
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.
In article <r5h9i.11996$13.11@nnrp.ca.mci.com!nnrp1.uunet.ca>,
Clever Monkey  <spamt@clevermonkey.org.INVALID> wrote:

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

--
Alan Curry
pac@world.std.com

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

On Tue, 05 Jun 2007 08:58:28 -0700, in comp.lang.c , David Mathog

<mat@caltech.edu> 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".

>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

In article <A4idnbTmKe8qP_jbnZ2dnUVZ8qDin@bt.com>,
Richard Heathfield  <r@see.sig.invalid> wrote:

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

--
Alan Curry
pac@world.std.com

Alan Curry said:

> In article <A4idnbTmKe8qP_jbnZ2dnUVZ8qDin@bt.com>,
> Richard Heathfield  <r@see.sig.invalid> wrote:

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

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

On Jun 5, 11:58 am, David Mathog <mat@caltech.edu> 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".

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

Alan Curry wrote:

> In article <A4idnbTmKe8qP_jbnZ2dnUVZ8qDin@bt.com>,
> Richard Heathfield  <r@see.sig.invalid> wrote:

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

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

Alan Curry wrote:
> In article <r5h9i.11996$13.11@nnrp.ca.mci.com!nnrp1.uunet.ca>,
> Clever Monkey  <spamt@clevermonkey.org.INVALID> wrote:
>> 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?

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.

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

I'm at a loss to explain how you got to what I said to "lobby".
--
clvrmnky <mailto:spamt@clevermonkey.org>

Direct replies will be blacklisted.  Replace "spamtrap" with my name to
contact me directly.

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.
--
clvrmnky <mailto:spamt@clevermonkey.org>

Direct replies will be blacklisted.  Replace "spamtrap" with my name to
contact me directly.

... 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.
--
clvrmnky <mailto:spamt@clevermonkey.org>

Direct replies will be blacklisted.  Replace "spamtrap" with my name to
contact me directly.

"David Mathog" <mat@caltech.edu> wrote in message
> 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.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Lew Pitcher <lpitc@teksavvy.com> wrote:
> 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.

--
C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

On Tue, 05 Jun 2007 09:53:31 -0700, in comp.lang.c , David Mathog

<mat@caltech.edu> wrote:
>Ben Pfaff wrote:
>> David Mathog <mat@caltech.edu> writes:

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

Richard Heathfield <r@see.sig.invalid> wrote:
> 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.

--
C. Benson Manica           | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com      | don't, I need to know.  Flames welcome.

On Tue, 5 Jun 2007 17:50:40 +0000 (UTC), in comp.lang.c ,

pac@TheWorld.com (Alan Curry) wrote:
>In article <r5h9i.11996$13.11@nnrp.ca.mci.com!nnrp1.uunet.ca>,
>Clever Monkey  <spamt@clevermonkey.org.INVALID> wrote:

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

Neither. IMHO it proves only that the ISO committee felt that files
were commonplace enough, and yet sufficiently in requirement of
standardisation, that adding support via streams was useful. Whereas
directories were neither sufficiently supported, not sufficiently in
need of a common API.

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

Presumably you have a reason for making that statement up, but its not
clear what it is.
--
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 wrote:
> 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.

To that list, I can add *HP NonStopKernel*, I guess the installation at
AOL uses the Unix like interface, but many still run under Guardian,
which means no directories.

NSK is used all over world, for critical systems:

http://h20223.www2.hp.com/NonStopComputing/cache/76385-0-0-0-121.html

Guess what, NSK has a C compiler. :)

--
Tor <torust [at] online [dot] no>

pac@TheWorld.com (Alan Curry) writes:
> In article <A4idnbTmKe8qP_jbnZ2dnUVZ8qDin@bt.com>,
> Richard Heathfield  <r@see.sig.invalid> wrote:

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

Systems that don't have files are typically embedded systems, and
typically have freestanding C implementations (as opposed to hosted
implementations).  A conforming freestanding implementation needn't
support most of the standard headers at all.  In other words, the
typical way to handle fopen() for systems that don't have files is not
to provide it at all, not to have it always return NULL.

It turns out to be a lot easier to define a portable file interface
than to define a portable directory interface.  For example, you'd
need to define a way to construct file names from directory names.  On
Unix-like systems, you can join the directory path elements together
with '/' characters.  On VMS the syntax is much more complex
("SYS$FOO::[DIR1.DIR2.DIR3]FILE.TXT", or something like that).  And,
as RH pointed out, some mainframe systems support files, but don't
support directories in any meaningful sense.

--
Keith Thompson (The_Other_Keith) k@mib.org  <http://www.ghoti.net/~kst>
San Diego Supercomputer Center             <*>  <http://users.sdsc.edu/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

On Jun 5, 8:58 am, David Mathog <mat@caltech.edu> wrote:

This thingy has a directory abstraction, and is useful for C projects:
http://legacy.imatix.com/html/sfl/

For C++, I prefer this:
http://www.cs.wustl.edu/~schmidt/ACE.html

When you code to one of those standard APIs, your code does not have
to change from system to system.

So why not just fold stuff like the above into the C and C++
standards?

While we could ignore directory services for things like toaster ICs
and other embedded systems, there is still a problem.
The SFL works for POSIX and Windows type systems.  No soap on IBM
Mainframes running MVS or VSE and many other systems.
Same for ACE.  So it only works on a subset of hosted systems.  The
whole point of a nationwide or worldwide standard is that it gives you
a guarantee of how things are supposed to work.  But since we can't
make it work that way, we would have to invent a new fork in the
standard:
Hosted, hosted pathless, non-hosted.  A bad precedent I think.  So why
not just use an existing toolkit that will do what you want to do in
the environment you need to do it in?  (After all, you don't usually
need to navigate folders on z/OS except on hosted subsystem operating
systems).

David Mathog <mat@caltech.edu> wrote:

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

Inertia.

--
SM Ryan http://www.rawbw.com/~wyrmwif/
Leave it to the Catholics to destroy existence.

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc