Re: encapsulating directory operations

"Richard Heathfield" <rjh@cpax.org.uk> wrote in message
news:100i43s$29dr0$1@dont-email.me...

[This should be fun.]
>
On 20/05/2025 14:47, Paul Edwards wrote:

"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

>
directory.h, damn you! Folders are for schoolteachers, not
programmers. We could fall out over this.

What we'll fall out over is you exceeding the limits of
MSDOS 8.3 filenames. :-)

ISO C90 didn't do that.

And yes, I counted it on my fingers.

I suspect Jean-Marc chose "folder" because every man
and his dog has a directory-processing "standard" and
he could see that none of them were doing what I wanted
and I was struggling to express myself.

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.

>
Whether you agree with David or not, he's correct. He has
accurately described the way the world sees C.
>
You might argue that the world sees it wrong, and who am I to
dissuade you? But ISO has far more clout than you or me, alas.

Oh - I guess in that light, he is indeed correct. English is
*defined* by common usage, so yes, the definition of C
is thus the latest and greatest standard, regardless of
whether there are any compilers at all that support that
language.

The world is a joke.

I've already given someone else's take on that. I just
agree with him.

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.

>
Mibs are marbles. You can't run a C compiler under 16 marbles,
not even if you bring in Dennis Ritchie.

Pardon? I also use Microsoft C 6.0 which was the
last version to run on a PC XT in 640 KiB.

gcc 3.2.3 will run in under 16 MiB if I switch off optimization.

I understand where these people are coming from.

>
So do I, but I expect it was a typo for 16 GB.

Nope.

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.

>
Right.

Certainly great to have company!

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

>
I'm afraid we're about 13� years too late to expect an answer
from the man himself, but I could guess at his answers:
>
(a) nothing;

EXACTLY.

(b) they make a reasonable library, but there's no reason to
change C90. If people find the library useful, they will use it
and the word will spread.
>

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.

>
Then what do you mean by it? I suspect David thinks you mean an
update to the ISO C90 document requiring all conforming C
compilers to adopt your new library. And, like me, Keith and
David know full well that that ain't gonna happen.

Oh my goodness.

No, no. I'm not expecting that.

You can call it C25 if you want. And C25 is a slight change from C90.

Or C90+

Or possibly C90+- if say gets() is removed.

And other things - like things that SubC is struggling to provide -
could potentially be removed to have multiple "levels" of "minus".

The SQL standard I read in the 1990s had 3 levels.

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

>
If you want to publish a library, nobody is going to argue
against you doing so. You can't have too many libraries. (Well, I
expect you can, but it's hard.)

I can publish lots of libraries for lots of applications.

This wouldn't be one of those.

This would be something fundamental for a portable lingua franca.

I've mentioned before about adding a define for:

#define ESC_STR "\x1b"
#define ESC_CHAR 0x1b

ready for recompiling on an EBCDIC machine to support an
EBCDIC ANSI X3.64 terminal.

So this is another one of those. A portable way of dealing with
a hierarchical file system. Even on a system like MVS/TSO
that doesn't have such a thing, so needs some cautionary
wording.

C90 is full of cautionary wording and a joy to read.

Or to put it another way - if you didn't have time pressure,
and the world was willing to stop writing code circa 1986
until C had been standardized, and with the benefit of
hindsight - what should or shouldn't be in a C90 or C2090 -
however long it takes to "get it right"?

BFN. Paul.