Re: encapsulating directory operations

On 2025-05-20, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

"Paul Edwards" <mutazilah@gmail.com> writes:

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a5770xjw.fsf@nosuchdomain.example.com...

"Paul Edwards" <mutazilah@gmail.com> writes:
[...]

So is it right to expect directories to be covered by C90?

>
Of course not.  C90 is frozen, defined by the ISO standard published
in 1990.  It is an obvious fact, that you cannot have missed,
that the C90 standard does not support operations on directories.
(Neither does any later ISO C standard.)
>
I'm guessing that you meant something by "expect" that differs from
its usual meaning.  Can you clarify?

>
When C90 was being written - or indeed - when K&R was
being written - if there hadn't been pressure to "bring to market",
would you EXPECT a language standard - any language
standard - but in this specific instance the ISO/IEC 9899:1990
committee - to have included a standard form of directory
manipulation?

>
Ah, that's a very different question.  I have no answer, because
I don't care.  C90 is what it is.  Of course it could have been different.
>
[...]
>

As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.

>
None that I can think of.

There was a significant barrier. The ANSI group which standardized
C was mainly looking at surveying and codifying existing practice.

They were not doing wholesale invention of mechanisms not already
portable.

They did add some things like the void type from C++ and function
prototypes, inventing the (void) parameter list not found in C++ for
denoting a prototyped empty list (which C++ then copied back).

Directory manipulation could be added to C similarly to the way
threading was added: new platform abstractions that are implementable in
terms of POSIX and other system interfaces.

There could be some challenges there worse than threads, due to
differences in path handling and other conventions.

There is a difference between directory handling and threads in
that threads serve the program. You select the threading interface,
like POSIX or C11, and you design the solution around that.
Directory handling is often imposed externally: programs processing
directory trees are often expected to do so with high fidelity
with respect to all the bells and whistles of the given system:
permissions, time stamps, ACLs, file types beyond just file
versus directory.

A half-baked directory access interface that serves only a
small subset of programs (which access only their own file-based
data model that can be constrained to fall within the limitations)
is not going to be worth pushing all the way up into the
language standard.

Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.

I implemented something like this. It is fine; I don't regret it.

i1> (open-directory ".")
#<dir-stream b7b90820>
2> (get-line *1)
"htrailer.txr"
3> (get-line *1)
"y.output.bison"
4> (get-line *1)
"jmp.S"
5> (open-file "/etc/hosts")
#<file-stream /etc/hosts b7b7a8b0>
6> (get-line *5)
"127.0.0.1\tlocalhost"
7> (get-line *5)
"127.0.1.1\tsun-go"

Paul's proposed refinement of a trailing slash to indicate directories (versus
any other filesystem object kind) is absent. You have to call an additional
function if you want to know.

I don't use this open-directory very much because there are other ways to get
directory entries, like the ftw function (traverses trees), or glob (matches
patterns).

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca