Re: encapsulating directory operations

"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.

Can also check to see if the user has pressed a keystroke
during the file transfer. Without blocking.

And without a whole massive multi-threading overhead
which wouldn't exist on a "simple" (it's not simple when
you have to write it yourself) system like MSDOS.

If fpeek had been added to the C90 standard, would you have
considered that to be odd/wrong? If so, why? If not, what form
should it have taken?

>
I have no opinion on that.

Ok, I'm here for opinions in case anyone else wants to chime in.

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.

Or my committee where I can't get any compiler vendor
at all (except for the compilers I control) to add such a thing.

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?

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.

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.

So I don't know what the alternative is to updating the
language standard.

I can't think of any other way to control an ASCII/EBCDIC
ANSI X3.64 terminal without language/library support.

BFN. Paul.