3

Is POSIX a description of how applications have implemented each specific part of UNIX in the past or is it a prescriptive norm of how UNIX must be implemented ?

If descriptive, only the features that are common to all included implementations would be valid. While any implementation have not implemented a feature, that feature is "undefined".

If prescriptive: On which theoretical framework is it based? Math? C language? Experience?

7

It's prescriptive de jure, but mostly descriptive de facto.

POSIX is a set of specifications that implementations can be matched against, including both implementations that already exist when the document is published and future implementations. So it's prescriptive.

In practice, POSIX started mostly as a common subset of existing implementations. So in this sense, it's mostly descriptive. But POSIX sometimes mandates new behavior. Most commonly, for features that existed in many implementations but with different interfaces (function names, command line options, etc.), POSIX has introduced several functions and utilities, such as pax (a replacement for tar and cpio, which were very different across Unix variants) and various posix_xxx functions. POSIX also introduced new constant and command line options; for example, for ps, “The -A option is equivalent to the BSD -g and the SVID -e. Because the two systems differed, a mnemonic compromise was selected.”. The rationale sections often explains why this or that feature was included, often mentioning which implementations already had a feature, or why a choice was made or not made between incompatible implementations.

| improve this answer | |
2

The intention of POSIX is to describe existing behavior and not to break historic behavior (not to make historic UNIX non-compliant) unless the historic behavior could be seen as a definite historic bug already.

The further intention of POSIX is not to introduce own invention. If it turns out that there would be a need for so called own invention (because existing implementations are not useful for a standardization), the ideas from the POSIX committee are discussed with the authors of various UNIX (or program) versions in order to get the best solution. Such a discussion frequently results in new implementations that support the final proposal at the time they are written down already.

There are a few exceptions, POSIX e.g. defined getpgrp() and setpgrp() in a way that is in conflict with the BSD interfaces that existed 10 years earlier already. POSIX defined getline() and fexec() in a way that is completely incompatible with implementations that existed for nearly 30 years before introducing the incompatible interfaces from the GNU libc.

If it turns out that existing implementations do not match, a decision is made which variant is used (or whether a mixture of existing different implementations is introduced) and a posix specific name is introduced. This happened e.g. for the thread interfaces, where posix_xxx() functions have been introduced that are very similar to the previous reference implementation from Roger Faulkner (Sun Microsystems).

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.