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: Wed, 21 May 2025 11:06:36 -0700 Organization: None to speak of Lines: 167 Message-ID: <87a575zvmb.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> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Wed, 21 May 2025 20:06:38 +0200 (CEST) Injection-Info: dont-email.me; posting-host="151d526d8f9bb67aa0331e0f184aea14"; logging-data="3105645"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18heQ47hXIhcyIqYYquzSaH" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:KstFjen7+rx+0TQlz3CAW2Uxg3Y= sha1:mM/hMTve4KFes/TCOBn/5Z/jyU0= Xref: csiph.com comp.lang.c:393519 "Paul Edwards" writes: > "Keith Thompson" wrote in message > news:87ldqqzfj0.fsf@nosuchdomain.example.com... [...] >> Directory access is largely a solved problem. If you insist on >> creating yet another solution, I recommend following the existing >> solutions. > > Well - that would be: > > struct dirent > { [...] > } [...] > And rmdir() - also flexible - allow failure > > 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. [...] >> Do not mistake my idle comment for an endorsement. > > I don't need an official endorsement. What I need to know > is that you can't think of any philosophical reason that the > C90 committee shouldn't have done that - had they chosen > to do so. No, I don't believe you need to know that. I consider the question of what the C90 committee could theoretically have done in some alternate timeline irrelevant. [...] >> >> I think I've discussed ESC_STR with you before. >> > >> > But not to the point where these questions were answered: >> > >> > If ESC_STR had been added to the C89 standard, because >> > a majority of the committee had decided they wanted to >> > support basic ANSI X3.64, would you have considered that >> > to be odd/wrong? If so, why? If not, do you think the define >> > ESC_STR and ESC_CHAR are a bad naming convention, >> > and if so, what do you think would have been better, and why? >> > And what header file would you have put them in? >> > >> > If instead, C90 had already been published, and suddenly >> > committeee members realized they had forgotten about >> > ANSI X3.64 terminals and quickly formed a C91 standard >> > to add just this one feature, what header file would you >> > have put it in, and why? >> >> C90 *could* have added a way to refer to the escape character >> (which exists, with different values, in both ASCII and EBCDIC). >> The sensible way to do that would have been to allow a \e escape in >> character constants and string literals. Some languages have exactly >> that feature, and several C compilers support it as an extension. > > Ok, but for a C90+ or C91 or whatever standard - it would > require a change to the compiler itself to do the above. > > That would be reasonable for a new language, but not for > the C90 committee. There is no C90 committee. That was 35 years ago. > Or my committee where I can't get any compiler vendor > at all (except for the compilers I control) to add such a thing. You don't have a committee. Still, you claim to be creating a new language that happens to be based on C90. Are you adding a new constraint that any differences between C90 and your language cannot require compiler changes? Changing existing library implementations is not significantly easier than changing existing compiler implementations. There are open source implementations of both. > Updating a header file is a trivial change in comparison. > > So I think a header file is the proper way to go. > > Do you not agree with this? I do not. With this new information that you're unwilling to do anything that requires compiler changes, it seems to me that you can achieve your goals by taking an existing conforming C90 implementation and adding some library code (headers and implementation). > Or if you can at least understand why I would prefer a > header file - would you update an existing one or create > a new one (perhaps "c90ext.h" - C90 extensions), and > throw this define in - and what name would you give > this define? > >> No other special character values are defined as named constants >> in headers. > > Perhaps they should be. > >> Perhaps I would have favored standardizing \e at the time, but that >> ship sailed decades ago. I'd probably favor a proposal to add \e >> to C2y. > > This "ship sailed" is some sort of semantic issue. > > As you noted - C2y can be updated. > > And also I can create a C90+ standard outside of > anything ISO does. > > The ship hasn't sailed, from my point of view. The ship that has sailed is the C90 standard. One more time, C90 itself will not change. You're free to define your own language/library/whatever based on C90, but it will not be C90. > I have stayed in port for the last nearly 40 years. > >> In practice, if I need an escape character, I use '\x1b'. I've never >> needed to use an EBCDIC escape character. If I did, I'd use '\x27'. >> If I needed to support both ASCII and EBCDIC escape characters, >> I'd find a way to do that. > > Thats's my question - "find a way". Specifically - what way? > >> None of this requires language or standard >> library support. > > It is unclear to me why you are saying that. First of all, you > haven't specified what "find a way" is. 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. > So I don't know what the alternative is to updating the > language standard. You mean creating your own language standard based on the existing C90 standard. C90 itself will change. Please be clear on that point. > 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. I recall looking into this last time we discussed this, and ANSI X3.64 is defined in terms of ASCII. As far as I know, no existing terminal or emulator uses the EBCDIC escape character, and I see no need for a terminal that does so. (Terminals used with mainframes operate very differently.) -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com void Void(void) { Void(); } /* The recursive call of the void */