One of the primary goals of POSIX was to standardize and encode existing behavior, but the behavior of Unices is sufficiently divergent that many APIs are usele

One of the primary goals of POSIX was to standardize and encode existing behavior, but the behavior of Unices is sufficiently divergent that many APIs are uselessly underspecified. One especially hilarious case is close being impossible to use correctly in a cross-platform manner: on HP-UX, you must check for EINTR and try again; on Linux, close will close the file descriptor even if interrupted by a signal, so you must not try again [1]. Almost nothing is specified as being async signal safe. Tons of functions are thread-safe on bionic or glibc but not other libc implementations (e.g. readdir, which has a readdir_r counterpart which should not be used [2]). Lots of APIs are fundamentally unusable in the presence of threads (e.g. there's no way to modify environment variables safely). This is a bit excusable, because pthreads were bolted on a decade after everything was already ossified. Lots of APIs are a giant pain in the ass to use compared to alternatives provided in Linux/BSD (e.g. alarm vs timerfd or kqueue). A few APIs are massive footguns that basically shouldn't ever be used. It's impossible to use POSIX shared memory without leaking. pthread_cancel is insane. 1: http://austingroupbugs.net/view.php?id=529 http://austingroupbugs.net/view.php?id=529 2: https://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html#index-readdir_005fr https://www.gnu.org/software/libc/manual/html_node/Reading_0...