Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: encapsulating directory operations
Date: Thu, 22 May 2025 18:38:52 -0700
Organization: None to speak of
Lines: 176
Message-ID: <87y0uot8b7.fsf@nosuchdomain.example.com>
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>
	<100ob9f$3n9m3$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Fri, 23 May 2025 03:38:53 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a36cf223f85aef33d75c7d55cd737c07";
	logging-data="3948976"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+L3ZhG8KVIoS2IkHUCrOqK"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:ewVCb72ShtbaU32JjWlAFMvRA30=
	sha1:m81jlqyTKfBFAS4aoyWUBFs3dqY=
Bytes: 7661

"Paul Edwards" <mutazilah@gmail.com> writes:
> "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.

It doesn't matter to me whether a directory management interface is
part of a language standard or not.  I don't know why it matters
to you.  C didn't standardize opendir(), but POSIX did, so I use
opendir() on systems that support it.

[...]

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

I don't believe that you personally will have any influence over any
future C standard.  Your goals are too different from the goals of the
committee and those of the vast majority of people who care about C.

[...]

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

In my opinion that will never happen.

I have no problem with whatever functionality you want to provide in
your PDPCLIB, and I'm willing to discuss some of it in technical terms.

[...]

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

I don't know what you mean by that.  If you mean that your PDPCLIB
library IS "C90+", that's fine; both are your invented terms.
But it's an odd choice of terminology.

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

That will not happen.

> Actually influencing ISO is a separate exercise.

That will not happen either.

> It probably won't involve coercion.
>
> But coercion wouldn't be required if the C90+ committee comes
> up with something reasonable.

That sounds like a threat.  If it is, I suggest you stick it where the
sun don't shine.  But as far as I know you have no ability to carry out
your threat, so it's more pathetically amusing that frightening.

[...]

> You can probably say that I have decided that future versions
> of C will only work on character sets that include an ESC
> character.

That is not your decision to make.  (Nor is it mine.)

[...]

> And if I am one day elected president of the USA, at the
> same time as Chancellor of Germany, and a few other
> places, you may well find 90% of the planet using it (or
> at least, having it on their system).

See above regarding "where the sun don't shine".
========== REMAINDER OF ARTICLE TRUNCATED ==========