Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson 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" writes: > "Keith Thompson" 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" writes: >> > "Keith Thompson" 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 ==========