|
|
 |
 |
 |
 |
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.
Kenneth Brody wrote: > 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".
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.
Clever Monkey wrote: > Kenneth Brody wrote: >> 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". > 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. -- 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:
> 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????
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.
|
 |
 |
 |
 |
|