Path: ...!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: Wed, 21 May 2025 08:38:44 +1000 Organization: A noiseless patient Spider Lines: 155 Message-ID: <100j09o$2f04b$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> Injection-Date: Wed, 21 May 2025 00:38:50 +0200 (CEST) Injection-Info: dont-email.me; posting-host="7d0475afa27e16a08c1e6e0485f4228c"; logging-data="2588811"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18HRSN4AbyVn0mj4C9S7s1qYs0KEGo0tHk=" Cancel-Lock: sha1:l/+boz/i+ACl1XIT806qI7Y1USE= X-Priority: 3 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MSMail-Priority: Normal Bytes: 6616 "Keith Thompson" wrote in message news:87a5770xjw.fsf@nosuchdomain.example.com... > "Paul Edwards" writes: > [...] > > So is it right to expect directories to be covered by C90? > > Of course not. C90 is frozen, defined by the ISO standard published > in 1990. It is an obvious fact, that you cannot have missed, > that the C90 standard does not support operations on directories. > (Neither does any later ISO C standard.) > > I'm guessing that you meant something by "expect" that differs from > its usual meaning. Can you clarify? When C90 was being written - or indeed - when K&R was being written - if there hadn't been pressure to "bring to market", would you EXPECT a language standard - any language standard - but in this specific instance the ISO/IEC 9899:1990 committee - to have included a standard form of directory manipulation? Manipulating directories is not as important as manipulating files. The C90 people didn't leave out file manipulation (I think the ISO Pascal people left it out, at least originally). So the C90 people did a better job than the Pascal people. Although that's partly my question - what belongs in a language standard? Maybe the Pascal people got it right, and C90 shouldn't have included a library at all - that should have been a completely different document. But manipulating directories is still very important. As far as I know, there was never any LOGICAL barrier to including basic directory manipulation in C90. There were presumably some mainframe people hanging around who said "you can't add directory manipulation - directories don't exist on normal MVS". Which isn't completely true. And there would have been a time constraint too - we'll add directory manipulation separately. But I'm not interested in time constraints or personality constraints. I'm interested in logical constraints. > There is an existing secondary standard that does provide support > for directories, among a lot of other things. POSIX. If I wanted > a system that was based on C90 and could handle directories, > I can't think of a good reason not to use C90+POSIX. (You might > have ideological reasons to insist on an earlier edition of POSIX.) > > (MS Windows does not directly support POSIX, or at least does not > do so usefully, but my impression is that you don't care about that.) That is incorrect. I do care about Windows. And MSDOS too. Both support directories. So any standard for directory manipulation would need to cover them. And cover mainframes too. You could argue I could take just the subset of POSIX that refers to directory manipulation. And then subset that further to only include the filename. But then I'm missing the directory flag. I could subset their flags. Or I could do what the folder.c routines do an add a "/" indicator at the end. The latter seems neater to me. But it could potentially be even neater if it was hidden away behind a standard fopen etc call. That's my question. > If you want to define your own language based on C90, you're free > to do so. You've talked about "extending" C90. Some people here > have interpreted that to mean you want to change what C90 is, so > there's something called "C90" that includes some stuff you've added. > Calling your language "C90" will cause confusion and some anger. > But you can do exactly the same thing by defining a *new* language > *with a different name* that's based on C90 with whatever additions > you want. The name can even start with "C", just as "C++" does. Sure. I've previously mentioned C90+ or C90+- I don't really care what the name is. It would only be a working name at this point in time. > Many of us think that would be a waste of time, but it's not our > time that's being wasted. Sure - I don't expect everyone (or anyone) to agree that it is useful. > And if you want your new language to support directory operations, > my advice would be to incorporate POSIX directory operations into > your new language's standard library. Why not hide it in fopen()? That's my original question. Why should it be opendir() instead of fopen()? That's my unanswered question. Plus you just said above that it would be reasonable for the POSIX directory operations to be directly incorporated into C90+'s "standard library". The C90 people didn't choose to do that. That doesn't necessarily constrain the C90+ people. But it does beg the question - would it have been ACCEPTABLE for the ANSI 89 people to have put that directory manipulation stuff into the C89 standard IF they could do so quickly? Or would that be an ABOMINATION? What is the PHILOSOPHY about what SHOULD be included in a standard? >> I don't see what bearing my opinion on C99 (or politics, >> or anything) has on a technical discussion of C90, but >> so be it. > It *should* have no bearing at all. The problem is that if you > come here and say that C99 is a "complete and utter joke" or make > similarly inflammatory statements, people are going to react. > If you don't want that reaction, don't make statements like that. I didn't say I didn't want the reaction. I don't care if there is or isn't a reaction. What I care about is whether the technical question has been addressed or not. It hasn't been addressed. Nor has fpeek() in a previous thread. Nor ESC_STR. YMMV. BFN. Paul.