3 ms·

> holds us to a C-based API/ABI This shows a bit of a misunderstanding about what POSIX is. It isn't about operating systems, it (IEEE 1003.1) is about source

> holds us to a C-based API/ABI This shows a bit of a misunderstanding about what POSIX is. It isn't about operating systems, it (IEEE 1003.1) is about source-code compatibility for 2 languages: C99, and Shell. POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. Totally non-UNIXy systems like z/OS are POSIX certified, because they have source-code compatibility with C99 and Shell programs written against POSIX; that doesn't mean it is held to a C-based API.

lomnakkus 9y ago
OK, I was technically wrong about ABI. Still, the ABI is (effectively) mandated by C which is (effecitvely) mandated by POSIX. Do we still have any quarrel over wording?
lomnakkus 9y ago
> POSIX doesn't say anything about an ABI, and there's nothing holding the system as a whole to a C-based API. It's specifying C compatibility, of course it's talking about a C API! If you want a different language API, POSIX (1003.1) isn't relevant to you. (Double-replied because I wanted to separate this bit out.) Effectively, it seems you're saying: "Ok, you don't want to implement a C API"[1], well, jolly good luck to you, then. The premise of this whole conversation was that POSIX was a dominating force, and now you're saying you don't have to participate...? [1] A C API, obviously, requires an extreme amount of either 1) being C, or 2) being compatible enough with C that it doesn't matter either way, or 3) giving up entirely on the POSIX ecosystem. So... how is that not being absurdly badly influenced by POSIX?