Path: csiph.com!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 15:32:08 -0700 Organization: None to speak of Lines: 130 Message-ID: <87bjrkxonr.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> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Fri, 23 May 2025 00:32:14 +0200 (CEST) Injection-Info: dont-email.me; posting-host="a36cf223f85aef33d75c7d55cd737c07"; logging-data="3890821"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/d8cm6woRAI8ye8nu6mLQ4" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:J4jk4dmGRVVLk4bEVYbFlAFVCoA= sha1:Ks3hxoH0g04WANo2MfipF40Btok= Xref: csiph.com comp.lang.c:393545 "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. 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. [...] >> 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. Apparently PDPCLIB is that library. 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. 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 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". It's just a library. It may or may not depend on features of the C90 standard library. The implementation of that library might have to be modified for different target systems. [...] >> 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. > 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. There's no portable way for the preprocessor to know whether the target character set is ASCII, EBCDIC, or something else, but can it be determined at compile time with a constant expression. Note that this will likely fail if the target character set is not based on either ASCII or EBCDIC. That's not likely to be relevant in the real world, and apparently you've decided for some reason not to care about the possibility. [...] >> > I can't think of any other way to control an ASCII/EBCDIC >> > ANSI X3.64 terminal without language/library support. >> >> But there's no such thing. [...] > There is - I produce one myself (via emulation) - do you > want me to give you a link? Proven against real mainframe > hardware (despite the claims that my software will never > run on a real mainframe). So there's one emulator that nobody other than you uses? Ok, fine, whatever. [...] -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */