Path: 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 20:41:07 +1000 Organization: A noiseless patient Spider Lines: 284 Message-ID: <100kak8$2q0s6$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> Injection-Date: Wed, 21 May 2025 12:41:13 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ab16efa0456b367b7db867c77fcb2fc0"; logging-data="2950022"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/brjRt4978E+g4r5J6LLWQYBSa4E0VUjE=" Cancel-Lock: sha1:qxzFxbZYi+i1Z/BKT46ZRyouQ5w= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-MSMail-Priority: Normal X-Priority: 3 X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 "Keith Thompson" wrote in message news:87ldqqzfj0.fsf@nosuchdomain.example.com... > It artificially merges two very distinct concepts for no good > reason that I can see. Operations that make sense for files make > far less sense for directories. There's no shortage of interfaces > for dealing with directories (POSIX, C++, Perl, etc.), and I'm not > aware of any of them that conflate directories and files. It's true > that "(almost) everything is a file" is part of the Unix philosophy, > and directories are typically stored as file-like objects with most > of the same attributes that files can have, but I can't think of > any good reason for higher level code to care about that. Thanks. That's a great answer. > 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 { char *d_name; /* of some sort */ int d_type; /* DT_DIR = directory or anything else = file */ } And opendir(), readdir(), closedir(). Plus mkdir() - subject to failure - and drop the second parameter as there is no such universal thing as permissions. If it does work, it is required to create an entire directory structure. And rmdir() - also flexible - allow failure Are you sure - given the constraints - that a different interface isn't appropriate? > > You may as well throw in the entire POSIX, the entire C23, > > and the entire C++ into C90 too. There needs to be some > > philosophy to set constraints. > > So invent a philosophy that meets your requirements. Sure. I'm having trouble articulating that. > > C90 wasn't designed by one person. K&R C was more-or-less > > designed by one person. But I don't want a language designed > > by one person. > > > > I want a language that is accepted by a committee. > > > > Not the C99 committee. Not the C23 committee. > > > > The C90+ committee. I would probably decide who gets > > to sit on the committee though. > > I would frankly be surprised if anyone other than you were willing > to be on that committee. Remember that being a member of a language > standard committee is a lot of work, and is typically unpaid. I've worked on PDOS unpaid for 3 decades. The authors of pdld, sasm have been working unpaid for years too. Scientists often experiment on themselves - I think there is a problem of morality doing it any other way. The nature of the beast means that this work is unpaid too. Plenty of people make donations or "sponsor a child". That is effectively doing unpaid work too. > > Richard would probably be on the committee, as he has > > a shared goal. It's not likely that he wants to though, and > > note that the committee doesn't formally exist yet. And > > nor does it need to formally exist. It is enough to have > > a discussion in comp.lang.c and when you, Keith, give > > the go-ahead for directory manipulations to have been > > incorporated into C90 - because you can't see anything > > wrong with it - then the theoretical committee can > > continue their work on directory manipulations in C90+. > > 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. > >> > 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. > >> > >> Right. > >> > >> > 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? > >> > >> Yes. > >> > >> > Or would that be an ABOMINATION? > >> > >> No. (WTF??) > > > > I don't understand your question. > > If you don't know what "WTF" means, I suggest a web search. I knew that already. > I was > expression surprise that anyone would use a loaded word like > "abomination" for something so innocuous. I don't consider it to be "innocuous". Until fairly recently, I thought it was impossible to do on the mainframe and would have excluded that class of machine. > > I have a series of questions that begin with: > > > > If xyz had been added to the C90 standard, would you have > > considered that to be odd/wrong? If so, why? > > I'm unlikely to be interested in answering most of those questions. > I don't see how they're in any way relevent, even to what you're > working on. I have no objection to a new language based on C90, > but agonizing about what the C90 committee should or should not > have done is IMHO a waste of time. It's for guidance purposes. If the C90 committee balked - I want to balk too. > >> > It hasn't been addressed. Nor has fpeek() in a previous thread. > >> > Nor ESC_STR. > >> > >> I don't remember what fpeek() is supposed to be; > > > > See if a stream is known to have characters in it. > > I'd need a more precise explanation. Does it just return a > true/false value? That's my question to you. But no - I would expect it to return a count of the characters definitely available for reading on the stream. > If so, how does it differ from feof() and/or > ferror()? Surely both of those are very different concepts? So - it differs dramatically. If I inspect a file, and it hasn't yet hit eof, and it so far doesn't have an error - that in no way means that I can read at least 1 more byte from the stream. And if there isn't 1 more byte from the stream, I will block. I don't want to block. > What would it do on an interactive stream? Warn me whether I will block. > What is the use case? zmodem file transfer. Open COM1. See if there is a pending ZNAK in the middle of the transfer. Without blocking. ========== REMAINDER OF ARTICLE TRUNCATED ==========