Re: encapsulating directory operations

"Keith Thompson" <Keith.S.Thompson+u@gmail.com> wrote in message
news:87a5770xjw.fsf@nosuchdomain.example.com...

"Paul Edwards" <mutazilah@gmail.com> 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.