Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!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 09:16:59 +1000
Organization: A noiseless patient Spider
Lines: 246
Message-ID: <100ob9f$3n9m3$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><100o3sc$3ll6t$1@dont-email.me> <87bjrkxonr.fsf@nosuchdomain.example.com>
Injection-Date: Fri, 23 May 2025 01:17:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="fb9946c96c96ac5c4fea82df78eac03e";
	logging-data="3909315"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19ljf8gKLmyLwhktepd9C+BNzEaFWkk7uk="
Cancel-Lock: sha1:ZqQoWIBYNwMne0fWh9TLH5nVx7k=
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-Priority: 3
X-MSMail-Priority: Normal
Bytes: 10490

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

Hi Keith.

I can now see a series of disconnects.

But hopefully now I can articulate the issue.

> "Paul Edwards" <mutazilah@gmail.com> writes:
> > "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?
>
> You've been given at least three; you didn't mention POSIX.

No. That's not a language standard. Only in Common Lisp
and C++ 17, so far mentioned, has the actual language
standard - rightly or wrongly - another outstanding question -
was it right or not? - covered directories.

> The POSIX interface (readdir et al) happens to be the one I'm most
> familiar with.  In fact it's pretty much the only one I'm familiar with.
> I have no comment on the others.
>
> As I've said before, I don't think your idea of doing directory access
> via fopen() is practical.

Sure. You explained that operations on directories are
different from operations on files, and it would nominally
be wrong to shoehorn directory access into a FILE
stream.

I didn't see anyone dispute that.

Although having said that - if FILE is a misnomer and really
means STREAM - perhaps directory access is also a stream,
and some streams require additional operations, e.g. streamMkdir().

> >> 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.
>
> If you're going to stick with existing C90 compilers, it seems
> to me that all you need for your purposes is an add-on library.

Here's the first disconnect.

Yes - I already have an add-on library - that's the folder.c and
folder.h I referenced in the beginning. And unistd.h would be
another.

But neither of these are in C23. Nor were they in C90.
I want a slight variation to BOTH of those standards,
and for the next ISO standard - C30 or whatever -
to include that slight variation.

(I didn't previously state this, because I wasn't aware
of it, again)

> Apparently PDPCLIB is that library.

No. PDPCLIB is just one of many, many C90-compliant
libraries.

> All your talk of defining
> a new language based on C90 (whether you call it C90+, or C91,
> or whatever), as far as I can tell, is not useful.

I apologize for not having the ability to express myself.
I can only see in hindsight what the issues are.

In this case, the plan is that my "add-on library", is so
small, and so useful, and hopefully so popular, that it
gets standardized into a theoretical C30, as well as
existing C90 libraries - including but not limited to
PDPCLIB - updated to include this new feature, that,
in hindsight, should have existed even in K&R C.

> C has *always* been designed to work with libraries in addition to
> the standard library.  POSIX is just one example.  Win32 is another.
> And there are countless other libraries, large and small.  You don't
> want to change the core language (Section 6 of the standard).
> You don't need to change the standard library (Section 7); you can

Disconnect. I didn't say "need". The word is "want".

> either use it as it's defined or ignore it.  You can create and
> document your own library that does whatever you want.  It doesn't
> have to be a "standard".

Disconnect. Not "have" - "want".

>  It's just a library. It may or may not
> depend on features of the C90 standard library.

No. It IS C90+.

> The implementation of that library might have to be modified for
> different target systems.

Of course. The language library standard simply says what is required.

> >> I have: "support both ASCII and EBCDIC escape characters".  It's not
> >> something I've ever needed to do, so I have not spent time or effort
> >> deciding how to do it.
> >
> > The C90 committee was forced to consider that. That's why
> > 'A' to 'Z' are not guaranteed to be consecutive, but '0' to '9' are.
> >
> > Without either ASCII or EBCDIC mentioned in the C90 standard.
>
> I was specifically talking about the ESCAPE character, which the C90
> committee ignored.

Sure. Sorry - loose language. They were forced - begrudingly
from what I think I remember I read - to consider the mainframe
implications. And most couldn't understand why the mainframe
was so complicated, with record formats etc.

> > Regardless, that's what I'm after - a decision on how to do it.
> > If you personally don't want to spend the time and effort and/or
> > make a decision, that's fine - I'm hoping someone in the group
> > will do that, and perhaps when they propose a solution you will
> > chime in and say "no, that's not a good idea for xyz reason".
>
> In one of your library's headers:
>
> extern const char ESCAPE;
>
> In the corresponding *.c file:
>
> const char ESCAPE = ('z' - 'a' == 25 ? '\x1b' : '\x27');
>
> Change the name if you prefer.

Disconnect. Not what I prefer. What the theoretical committee decides.

This is intended to be in the official ISO C standard for the next
1 million years.

Actually influencing ISO is a separate exercise.

It probably won't involve coercion.

But coercion wouldn't be required if the C90+ committee comes
up with something reasonable.

That's the goal. Something reasonable.
========== REMAINDER OF ARTICLE TRUNCATED ==========