Re: encapsulating directory operations

"Paul Edwards" <mutazilah@gmail.com> writes:

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

Ah, that's a very different question.  I have no answer, because
I don't care.  C90 is what it is.  Of course it could have been different.

[...]

As far as I know, there was never any LOGICAL barrier
to including basic directory manipulation in C90.

None that I can think of.

[...]

But it could potentially be even neater if it was hidden
away behind a standard fopen etc call.
>
That's my question.

Sure, it would be theoretically possible to treat directories as files,
and to make reading from a FILE* resulting from calling fopen() with a
directory name give you access to the directory entries.

I don't think it would be a particularly good idea.

[...]

Why not hide it in fopen()? That's my original question.
>
Why should it be opendir() instead of fopen()?
>
That's my unanswered question.

You won't get a definitive answer.  In your own language, you can
do it that way or not.  My opinion on whether it's a good idea is
irrelevant, since I won't be using your language.  I might have
some interest in it being logically consistent, but directories do
not seem to present any such issues.  You can use fopen(), you can use
opendir(), you can invent your own functions, you can leave it out of
the language and depend on outside standards and/or libraries.

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??)

What is the PHILOSOPHY about what SHOULD
be included in a standard?

Different standards have different goals.  I cannot advise you what your
own standard should be based on, since I don't agree with or care about
your goals.

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.

If you post inflammatory statements here, people will react.  I'm asking
you, for the sake of avoiding noise in this newsgroup, not to post such
statements here.

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.

I don't remember what fpeek() is supposed to be; did you have a
question about it?  I think I've discussed ESC_STR with you before.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */