Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Tue, 20 May 2025 22:41:55 -0700
Organization: None to speak of
Lines: 202
Message-ID: <87ldqqzfj0.fsf@nosuchdomain.example.com>
References: <100h650$23r5l$1@dont-email.me> <20250520065158.709@kylheku.com>
	<100i2la$292le$1@dont-email.me>
	<87a5770xjw.fsf@nosuchdomain.example.com>
	<100j09o$2f04b$1@dont-email.me>
	<87tt5ezx9y.fsf@nosuchdomain.example.com>
	<100j4t3$2foah$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Wed, 21 May 2025 07:42:02 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="151d526d8f9bb67aa0331e0f184aea14";
	logging-data="2841629"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/qI/rTlByVwlSZmZ3Q9kbm"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:sMgSxn9UoMXPnVKITOzP8mqSuFQ=
	sha1:rFYjCy4fmhnDUBhnx6/WraOF6Jo=

"Paul Edwards" <mutazilah@gmail.com> writes:
> "Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
> news:87tt5ezx9y.fsf@nosuchdomain.example.com...
>> "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.
>
> My question is not "could", it is "should", or "ideally".
>
>> > As far as I know, there was never any LOGICAL barrier
>> > to including basic directory manipulation in C90.
>>
>> None that I can think of.
>
> Ok, that's a great start. That answers one of my questions.
>
>> > But it could potentially be even neater if it was hidden
>> > away behind a standard fopen etc call.
>> >
>> > That's my question.
>>
>> 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 don't think it would be a particularly good idea.
>
> Can you tell me why?

It artificially merges two very distinct concepts for no good
reason that I can see.  Operations that make sense for files make
far less sense for directories.  There's no shortage of interfaces
for dealing with directories (POSIX, C++, Perl, etc.), and I'm not
aware of any of them that conflate directories and files.  It's true
that "(almost) everything is a file" is part of the Unix philosophy,
and directories are typically stored as file-like objects with most
of the same attributes that files can have, but I can't think of
any good reason for higher level code to care about that.

Directory access is largely a solved problem.  If you insist on
creating yet another solution, I recommend following the existing
solutions.

....]

> You may as well throw in the entire POSIX, the entire C23,
> and the entire C++ into C90 too. There needs to be some
> philosophy to set constraints.

So invent a philosophy that meets your requirements.

....]

> C90 wasn't designed by one person. K&R C was more-or-less
> designed by one person. But I don't want a language designed
> by one person.
>
> I want a language that is accepted by a committee.
>
> Not the C99 committee. Not the C23 committee.
>
> The C90+ committee. I would probably decide who gets
> to sit on the committee though.

I would frankly be surprised if anyone other than you were willing
to be on that committee.  Remember that being a member of a language
standard committee is a lot of work, and is typically unpaid.

> Richard would probably be on the committee, as he has
> a shared goal. It's not likely that he wants to though, and
> note that the committee doesn't formally exist yet. And
> nor does it need to formally exist. It is enough to have
> a discussion in comp.lang.c and when you, Keith, give
> the go-ahead for directory manipulations to have been
> incorporated into C90 - because you can't see anything
> wrong with it - then the theoretical committee can
> continue their work on directory manipulations in C90+.

Do not mistake my idle comment for an endorsement.

>> > Plus you just said above that it would be reasonable for
>> > the POSIX directory operations to be directly incorporated
>> > into C90+'s "standard library".
>> >
>> > The C90 people didn't choose to do that.
>> >
>> > That doesn't necessarily constrain the C90+ people.
>>
>> Right.
>>
>> > But it does beg the question - would it have been
>> > ACCEPTABLE for the ANSI 89 people to have
>> > put that directory manipulation stuff into the C89
>> > standard IF they could do so quickly?
>>
>> Yes.
>>
>> > Or would that be an ABOMINATION?
>>
>> No.  (WTF??)
>
> I don't understand your question.

If you don't know what "WTF" means, I suggest a web search.  I was
expression surprise that anyone would use a loaded word like
"abomination" for something so innocuous.

[...]

> I have a series of questions that begin with:
>
> If xyz had been added to the C90 standard, would you have
> considered that to be odd/wrong? If so, why?

I'm unlikely to be interested in answering most of those questions.
I don't see how they're in any way relevent, even to what you're
working on.  I have no objection to a new language based on C90,
but agonizing about what the C90 committee should or should not
have done is IMHO a waste of time.

[...]

>> > It hasn't been addressed. Nor has fpeek() in a previous thread.
>> > Nor ESC_STR.
>>
>> I don't remember what fpeek() is supposed to be;
>
> See if a stream is known to have characters in it.

I'd need a more precise explanation.  Does it just return a
true/false value?  If so, how does it differ from feof() and/or
ferror()?  What would it do on an interactive stream?  What is the
use case?

[...]

> If fpeek had been added to the C90 standard, would you have
> considered that to be odd/wrong? If so, why? If not, what form
> should it have taken?

I have no opinion on that.

>> I think I've discussed ESC_STR with you before.
>
> But not to the point where these questions were answered:
>
> If ESC_STR had been added to the C89 standard, because
> a majority of the committee had decided they wanted to
> support basic ANSI X3.64, would you have considered that
> to be odd/wrong? If so, why? If not, do you think the define
> ESC_STR and ESC_CHAR are a bad naming convention,
> and if so, what do you think would have been better, and why?
> And what header file would you have put them in?
>
> If instead, C90 had already been published, and suddenly
> committeee members realized they had forgotten about
========== REMAINDER OF ARTICLE TRUNCATED ==========