Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Wed, 21 May 2025 09:57:18 +1000
Organization: A noiseless patient Spider
Lines: 241
Message-ID: <100j4t3$2foah$1@dont-email.me>
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>
Injection-Date: Wed, 21 May 2025 01:57:24 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7d0475afa27e16a08c1e6e0485f4228c";
	logging-data="2613585"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+G6jbu1Oq590bebxVUTNlOcbJGL4xlmJs="
Cancel-Lock: sha1:FZeZb4bDzPnA6fgJGCkl9MWIloQ=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MSMail-Priority: Normal
X-Priority: 3
Bytes: 9624

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

> > Why not hide it in fopen()? That's my original question.
> >
> > Why should it be opendir() instead of fopen()?
> >
> > That's my unanswered question.
>
> You won't get a definitive answer.  In your own language, you can
> do it that way or not.  My opinion on whether it's a good idea is
> irrelevant, since I won't be using your language.

YOUR personal opinion is NOT irrelevant to ME.

Regardless of whether you use or don't use "my language".
Or whether it even exists.

It is mostly a comment on C90.

ie did the C90 people do anything wrong, in your opinion?

> I might have
> some interest in it being logically consistent, but directories do
> not seem to present any such issues.  You can use fopen(), you can use
> opendir(), you can invent your own functions, you can leave it out of
> the language and depend on outside standards and/or libraries.

>> And I am not personally familiar with the philosophy of
>> language standards.

> Because there's no such thing,

Thanks for that opinion.

> nor does there need to be.

And thanks for that one too.

But perhaps you can elaborate, as I find that statement odd.

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.

One of the constraints was that they were merely trying to
document existing practice, not create a new language.

Although they added wonderful things like memmove().

And there were time constraints too.

And lack of hindsight constraints too.

> Different
> languages are designed by different people with different goals and
> motivations.  I doubt that anyone here can tell you anything useful
> about how your personal language should be defined.  You can do whatever
> you like.

It's not about me. Obviously I can do whatever I want.

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 probably wouldn't allow you personally to sit on the committtee,
because you appear to be hostile to the committee's goals.

But I would appreciate your guidance for the committee.

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

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

There are some things people consider to be abominations.

If the "far" keyword had been added to the C90 standard,
would that have been an abomination? Surely some will
say "yes". I have worked with people who think the whole
of C90 is an abomination and that only K&R C is acceptable.

> > What is the PHILOSOPHY about what SHOULD
> > be included in a standard?
>
> Different standards have different goals.  I cannot advise you what your
> own standard should be based on, since I don't agree with or care about
> your goals.

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?

Note that Ritchie himself objected to various things being
put into the C90 standard.

Why not you?

========== REMAINDER OF ARTICLE TRUNCATED ==========