- Seemingly anything to do with terminal devices or job control. (Allocating ptys, sending control sequences like ^D or ^Z, adding processes to a group that will all recieve terminal signals together, etc.)
- The existence of hard links as anything beyond a destination cache for symlinks.
Most operating systems have problems like these, but POSIX proceeds to enshrine them as unfixable 'features' rather than "DEPRECATED: DO NOT USE". (On the plus side, F_SETLK(W) and close seem likely to be fixed at some point and close doesn't tend to get maliciously exploited the way eg integer overflow does by C compilers.)
Every implementation of close, except on HP/UX, will close the file descriptor before returning upon a signal. But POSIX has actually approved posix_close, which will guarantee the proper, desired semantics. See http://austingroupbugs.net/view.php?id=529
The semantics of POSIX advisory locks were inherited; they codified the most widely used existing implementation. The ergonomics suck, but they offer one distinct advantage: you can query the PID of the lock holder, something not possible when a lock can be inherited. This can be useful for PID file locks where you can query the PID directly rather than trying to write and read it from the PID file; there's no loaded gun lying around, although there's still the TOCTTOU race between querying and kill'ing. In any event, "file-private" advisory locks are likely to be standardized and are already implemented by both Linux and FreeBSD. See http://austingroupbugs.net/view.php?id=768 The semantics are not coincidentally very similar to BSD flock, and the types similar to POSIX. Which is noteworthy because it's an example of how paying attention to POSIX and portability issues can help you triangulate the evolution of Linux interfaces down the road.
It's not like Linux is without its warts. The kernel's implementation of setuid & friends is per thread. That's not only horribly inconvenient semantics for 99% of use cases, it's a security nightmare. And glibc and musl must implement an obscenely complex dance to get process-wide, atomic behavior. There are also many legacy Linux interfaces that the project is committed to supporting because of its commitment to backwards compatibility. I don't understand the logic of pointing out all the anachronisms of POSIX (e.g. advisory locks) while ignoring the anachronisms of Linux.
I never said POSIX was perfect, and I'm not arguing to only stick to POSIX. There's no substitute for using your own good judgment. I'm simply saying that too many people don't appreciate the benefits of POSIX and portability more generally, which are substantial. The benefits aren't just the standard itself or the ability to use an alternative OS like FreeBSD--if you didn't care before you're almost certainly never going to--but the fact that every Unix vendor tracks the standard and, to a lesser extent, avoids gratuitous incompatibilities with other POSIX environments. Standardization signals important information about the stability of an interface, and the process of standardization channels the evolution of interfaces long before they become standardized (if ever). POSIX and the BSDs matter to Linux development; and they should matter to Linux developers even if they'll never run code outside of a Linux environment.
It's also worth mentioning that Red Hat basically steers POSIX, now, judging by the Austin Group Bugs issue tracker. So while some teams are rather antagonistic toward POSIX (e.g. Poettering and systemd team), others put considerable effort into it.
- http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-br... It's impossible to reliably close a file if you have active signal handlers that might be triggered.
- https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081 (discussed at https://news.ycombinator.com/item?id=17601581 "POSIX advisory locks are broken by design.")
- Seemingly anything to do with terminal devices or job control. (Allocating ptys, sending control sequences like ^D or ^Z, adding processes to a group that will all recieve terminal signals together, etc.)
- 'Basic' regular expressions (as in `echo baaar | grep 'a+' || echo WTF`).
- The existence of hard links as anything beyond a destination cache for symlinks.
Most operating systems have problems like these, but POSIX proceeds to enshrine them as unfixable 'features' rather than "DEPRECATED: DO NOT USE". (On the plus side, F_SETLK(W) and close seem likely to be fixed at some point and close doesn't tend to get maliciously exploited the way eg integer overflow does by C compilers.)