Re: encapsulating directory operations

"Lawrence D'Oliveiro" <ldo@nz.invalid> wrote in message
news:100jhor$2lgt3$4@dont-email.me...

On Wed, 21 May 2025 10:23:27 +1000, Paul Edwards wrote:
>

Your definition of "real world", is probably "not C90".

>
Precisely.
>

Your "real world" applications won't work on traditional MVS ...

>
Let's face it: MVS stopped being part of the "real world" a long time ago.
Just about the time IBM's mainframe business started circling the gurgler.

I don't agree with that.

Regardless, I'm not attempting to have a debate about the
definition of "real world".

That is an example of a system I wish to support. It existed
at the time the C90 standard came out.

(Also, I think it's called "z/OS" now.)

Right. Still exists in 2025 too.

And that's assuming you want to ignore my MVS/380 update.

I'm not saying *you* should support MVS. I'm not saying
the ISO C23 committee should support MVS.

I note that C90 *does* support MVS.

And I am saying that my proposed C90+ explicitly needs to
support MVS 3.8J as an important target that cannot be
ignored.

And you can add DEC/VMS too.

The key point about symlinks is they are not the same as hardlinks.

>
There is no such universal concept for either of those things,

>
Yes there is: they are defined in POSIX, which is an official standard,
after all.

An official standard that isn't even supported by Windows, which
is far more important than any POSIX system in existence. Except
z/OS obviously. But I'm not interested in the bolt-on z/OS Unix.

Yes - I acknowledge that a POSIX bandwagon exists.

And if people want to jump on it - that's fine - it's a free world.

I'm just saying that I rarely use a POSIX-compliant system,
but do use multiple C90-compliant systems.

And it is the latter that I wish to make small changes to.
Supporting what someone else called a "half-baked"
file system is just one of those several extensions I am
interested in.

Do note one more thing.

The C90 standard deferred to MVS - probably still does -
and says that you can't open a file as "w", then read it as
"rb" and write (a new file) as "wb", and still access (the
new file) with "r".

I was shocked when I saw IBM's C library lose the newlines
when I did the above, and went to look at the standard to
show that IBM was violating C90 - but it turns out they
weren't.

That sort of means you can't write a "zip" program portably,
against the theoretical C90 file system. Or you would have
to have flags to say which files need to be opened as text
or binary.

I do not agree with IBM's C library, and PDPCLIB does
not have that behavior, so that constraint could potentially
be dropped in a C90+ standard.

BFN. Paul.