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