Re: encapsulating directory operations

"David Brown" <david.brown@hesbynett.no> wrote in message
news:100hs85$27qbn$1@dont-email.me...

On 20/05/2025 11:36, Paul Edwards wrote:

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

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

>

And C90 (etc) could potentially be extended to include a folder.h

>
C90 will never be extended.  It was made obsolete by C99, which was

made

obsolete by C11, which was made obsolete by C23.  You're free to invent
your own language based on C90 if you like, but C went in a different
direction decades ago.

>
That depends on your definition of "C". Ritchie is no longer here to
adjudicate whether something close to C90 - in the spirit of the
original C, is the true successor to his language, and which one is
a complete and utter joke of no relation to anything he designed.
>

>
Once C was standardised - first by ANSI, then immediately afterwards by
ISO - the "definition of C" became clear.

Yes, I agree with that.

The language is covered by an
international standard, so "C" is the language defined by that standard.
  Thus "C" means "C23" at the moment - each newly published C standard
"cancels and replaces" the previous version.

I don't agree with this. I'm sure the ISO committee is keen
to "cancel" the previous work.

But I have a different opinion.

I doubt that I am alone. I'm probably in a minority, but so what?

Ritchie's opinion hasn't
had any connection to the "definition of C" since 1989.  I don't know if
he ever expressed a public opinion on C99, or the plans for C11.  I
would, however, be astounded if he had considered it "a complete and
utter joke of no relation to anything he designed".

Well, in the 1990s I had some work colleagues who were
incensed that I had converted some K&R C code to C90,
and called it "nancy C". I pointed out that Ritchie himself
had endorsed the standard, and they still didn't budge,
saying that he had become deranged or something like that.

From another corner I still deal with people who insist
that everything should be written in assembler.

And in another corner, there are people who claim that I
am at fault for not making "my" compiler (a slight variation
of gcc 3.2.3) run in under 16 MiB of memory.

I understand where these people are coming from.

And I can see the alternative described by that Jeff article
I referenced.

But my starting position is that I (sort of) can't personally
fault the C90 standard, and the assembler code produced
by a typical C compiler is exemplary, and that this is the
basis for the lingua franca of programming.

(And while I don't think that an "appeal to authority" argument has much
merit, he did say that he found Linux "quite delightful" as a
continuation of UNIX, and I would not expect him to have viewed your OS
ideas as productive.)

I'm not asking him to approve my OS ideas. I'm asking him
to explain what is wrong with the C90 that he approved of,
and whether my mentioned extensions are reasonable.

But Keith is absolutely correct here.  C90 is C90, and will remain that
way (baring the very unlikely possibility of minor technical corrections).
>
You can make your own libraries, and OS's, and extensions, and languages
- whatever makes you happy.  (And if you enjoy what you are doing, and
it's not harming anyone, then that's all the reason you need.  You don't
need approval from anyone else.  Don't let me or anyone else hinder you
enjoying yourself.)  However, nothing that you ever do will be an
extension to C90.

You seem to have a different definition of "extension to C90" to me, then.

Which is also fine.

Regardless, I intend to compete with the ISO committee, and
not so much start from scratch, as start from C90.

My branch may not appeal to a majority, but I'm not particularly
trying to appeal to a majority. I'm interested in appealing to the
people who I work with (e.g. author of pdld). And I'm also
interested in technical guidance from the majority who likely
have more technical skills than me, regardless of whether they
agree with my approach/goals or not (spoiler: they don't).

BFN. Paul.