Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Paul Edwards" <mutazilah@gmail.com>
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" <Keith.S.Thompson+u@gmail.com> 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 ==========