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: Fri, 23 May 2025 07:10:32 +1000
Organization: A noiseless patient Spider
Lines: 302
Message-ID: <100o3sc$3ll6t$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><100j4t3$2foah$1@dont-email.me><87ldqqzfj0.fsf@nosuchdomain.example.com><100kak8$2q0s6$1@dont-email.me> <87a575zvmb.fsf@nosuchdomain.example.com>
Injection-Date: Thu, 22 May 2025 23:10:37 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8e26e3256e2de863dc3da03e7d46c9a3";
	logging-data="3855581"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19uzlMmbZ9epvc9M+xl0aCuzTVsl+JjlL4="
Cancel-Lock: sha1:3cpIFsXj3FwEK5tWoRzutYHz1qU=
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MSMail-Priority: Normal
X-Priority: 3
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Bytes: 12774

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

Hi Keith.

First - thanks a lot of teasing out an unstated assumption.

I am often operating on a set of assumptions. But I don't
list them upfront because I don't actually know what
they are.

> > Are you sure - given the constraints - that a different interface
> > isn't appropriate?
>
> I have not said or implied that the POSIX directory interface is the
> only appropriate one.  It does have the considerable advantage that it
> already exists.
>
> My advice is to study and understand existing solutions before inventing
> your own.  I can't offer meaningful advice on what's appropriate for
> your language.

I have now been given two pointers. Common Lisp,
and C++ 17. Do you have any comment based on
your knowledge of those?

> >> Do not mistake my idle comment for an endorsement.
> >
> > I don't need an official endorsement. What I need to know
> > is that you can't think of any philosophical reason that the
> > C90 committee shouldn't have done that - had they chosen
> > to do so.
>
> No, I don't believe you need to know that.  I consider the question of
> what the C90 committee could theoretically have done in some alternate
> timeline irrelevant.

You're reading too much into my idle use of "C90 committee".

I'm not talking about what the personalities were or anything
like that. I'm trying to "set the stage". ie there were existing
machines - including 36-bit machines - that needed to be
supported. They can't just be dismissed as "museum junk"
so that you don't need to go through the intellectual exercise
of how best to support a 36-bit machine.

"My C90+ committee" (a theoretical construct), needs to
support 36-bit machines. They cannot be imagined out of
existence. Nor can mainframes. Nor can MSDOS, so the
committee may start agonizing over whether the add the
"far" and "near" keyword in due course, but that process
hasn't started yet.

> > Or my committee where I can't get any compiler vendor
> > at all (except for the compilers I control) to add such a thing.
>
> You don't have a committee.
>
> Still, you claim to be creating a new language that happens to be based
> on C90.  Are you adding a new constraint that any differences between
> C90 and your language cannot require compiler changes?
>
> Changing existing library implementations is not significantly easier
> than changing existing compiler implementations.  There are open source
> implementations of both.

And here you have managed to tease out the unstated assumption.

I can and do use closed-source compilers like Microsoft C 6.0
and Visual Studio 2022.

They produce fantastic code.

But I bring my own library to the table - PDPCLIB. I basically
never use Microsoft's library. Or Watcom or anyone else.

And I am happy to go to any platform (OS, not compiler),
and bring my own C library (and modify it as required),
and use whatever C compiler I happen to find on that
platform.

This has been done over 30 years, and I have refused to
put anything non-C90 into my library. Which upset some
people.

Only now - with the platforms I have immediate interest
in (mainframes, MSDOS, Amiga, Linux etc) covered to
my satisfaction by C90 - which for example included
changing a couple of paradigms that the IBM mainframe
library used - which also upset a lot of people - I am
considering putting non-C90 stuff into PDPCLIB.

Note that none of this stuff is being done to deliberately
upset people. I just don't want to be constrained by
decisions IBM made at the time - oh yeah - another
unstated assumption - nor do I want to be constrained
by existing code.

Existing code, existing libraries, existing standards, are
all important guides, but not hard constraints.

I have "no" interest in "fixing" bitwise precedents in
C90, for example. I reserve the right to change my
mind about that in 20 years from now or whatever
though.

But right at the moment, I am interested in issues that
came up when I assembled an entire ecosystem (OS
and toolchain), as well as supporting the existing
mentioned OSes.

I can't practically change Visual Studio, but even then,
I would be open to negotiation, if someone were to
say "look, all the extant compilers support xyz, and
if you zap offset 156383 of cl.exe in Visual Studio,
it will be brought into line with all the other compilers,
and xyz is the way forward", then I would indeed
consider compiler changes.

But I seriously doubt that xyz even exists, much less
that it could be "fixed" with a 1-byte zap.

So while I don't want to say "I refuse to change
existing compilers", in practice, that is the case.

What I am more likely to say is "I don't want to support
Microsoft C 5.1, even though it is freely available (as
part of the MSDOS 4.0 distribution - you need to use
Microsoft C 6.0, which isn't, or switch out to Watcom
or something".

Microsoft C 6.0 can compile PDOS and PDPCLIB as-is,
5.1 can't.

I'm not totally ruling out changing PDOS and PDPCLIB though.
I could potentially change them to support not just Microsoft
C 5.1 but also SubC, or an improved SubC.

So yeah - I'm happy to change the extant code that I care
about (which, unusually, is not a lot - I only care about my
toolchain/ecosystem - which is all C90-compliant).

Even though I only care about that, it so happens that
other people's C90-compliant code should work fine on
the ecosystem that I provide. But maybe one day in the
future I will invalidate all bitwise code that doesn't use
brackets appropriately. Or the other way around. But
right at the moment, I haven't diverged one iota from
C90.

Also right at the moment, PDOS-generic has a very
crude and awful directory listing mechanism, and I'm
looking to fix that, which is why I'm here to decide
my next move, as there are multiple ways to go.

In the past, I have just used MSDOS as a guide, as it
is a simple system, so they've probably solved the
problem already for all systems, including small systems.
But the DTA structure they use seems very inappropriate
to me. And so first I am asking about the theoretical
underpinnings of directories. I doubt that after hearing
about the theory, the conclusion will be "so DTA is
definitely the way to go!". But I don't want to prejudge
that.

> With this new information that you're unwilling to do anything that
> requires compiler changes, it seems to me that you can achieve your
> goals by taking an existing conforming C90 implementation and adding
> some library code (headers and implementation).

Yes.

> One more time, C90 itself will not change.  You're free to define your
> own language/library/whatever based on C90, but it will not be C90.

Yes, I acknowledge that long ago.

> > I have stayed in port for the last nearly 40 years.
> >
> >> In practice, if I need an escape character, I use '\x1b'.  I've never
> >> needed to use an EBCDIC escape character.  If I did, I'd use '\x27'.
========== REMAINDER OF ARTICLE TRUNCATED ==========