[pjmlp]

fopen is part of ISO C, supported by NDK, and pthread is a special case.

https://developer.android.com/ndk/guides/stable_apis

> Note that on Android, unlike Linux, there are no separate libpthread or librt libraries. That functionality is included directly in libc, which does not need to be explicitly linked against.

Better learn how much POSIX Android actually allows.

[moonchild]

> pthread is a special case

How's that? It's a posix api among many others which is implemented on android.

How about fork[0], which is one of the more maligned posix apis (as far as I know, no one has any big problems with pthreads). Or errno[1]. Lots of ugly garbage in android...

0. https://android.googlesource.com/platform/bionic/+/refs/head...

1. https://android.googlesource.com/platform/bionic/+/refs/head...

[pjmlp]

So what?

APIs that aren't part of NDK stable API contract are not allowed, and since Android 7 Google has started to implement security measures to kill processes that try to use private APIs, one of the reasons why termux is no longer.

Good luck using your beloved POSIX APIs and not being killed in random Android devices.

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