[josephg]

Thats a distinction without a difference.

According to this google result[1] open() / write() are officially part of posix, while fopen() is part of C. Whatever - that distinction misses the forest for the trees. Its the semantics of those methods that hold computing back. Not their syntax.

[1] https://www.mkompf.com/cplus/posixlist.html - I'd have read the spec itself but you have to buy it from IEEE. Blergh.

[pjmlp]

No it does not, a platform with ISO compliant C compiler is not required to support POSIX in any form.

By the way, since C11, there is no need for POSIX threads any longer.

C11 threads might be implemented on top of POSIX threads, or anything else that the compiler vendor thinks of.

[josephg]

Sorry; the mistake was mine in my earlier comment. I pointed to "the crufty parts of POSIX" in an effort to point vaguely to the UNIX filesystem abstractions - fwrite/write, socket fds, fsync / fsyncdata, as well as fork() and whatnot. I don't actually care about the POSIX spec itself, or how POSIX differs from C11 (or how any of that is wrapped by the equivalent methods in Java).

This caused a distraction from the point I was making - which is that there are other ways we can do computing that don't use this model for files at all. For example we could make file operations transactional, or make files semantically rich - like database objects. So files themselves aren't "buckets of bytes" that need to be parsed by each application which interacts with them. There's lots of other ideas in this idea space - but the yoke of millions of lines of legacy code makes it difficult to explore this space outside of toy programming environments. And I worry as a result we might be stuck with the unix model forever.

[moonchild]

specification https://pubs.opengroup.org/onlinepubs/9699919799/functions/o...