What Is the Meaning of "Posix"

What is the meaning of POSIX?

POSIX is a family of standards, specified by the IEEE, to clarify and make uniform the application programming interfaces (and ancillary issues, such as commandline shell utilities) provided by Unix-y operating systems.

When you write your programs to rely on POSIX standards, you can be pretty sure to be able to port them easily among a large family of Unix derivatives (including Linux, but not limited to it!); if and when you use some Linux API that's not standardized as part of Posix, you will have a harder time if and when you want to port that program or library to other Unix-y systems (e.g., MacOSX) in the future.

Why POSIX is called Portable Operating System Interface?

Before Posix, the Unix family tree was becoming very diverse and incompatible. A program written for one Unix was not compatible with a different Unix without significant porting effort.

Posix was one of the attempts to present a common set of utilities and programming interfaces so that your software would be portable to multiple versions of Unix.

Since Posix is about the interface and not the actual OS, it is possible to have a Posix facade on a non Unix OS (such as the Microsoft Windows Services for Unix presenting a Posix facade on top of Windows).

What is POSIX compliance and how does it affect me?

POSIX defines a set of C headers, System Interfaces, a Shell Command Language and Utilities, that a conforming system must implement.

As a developer, you can rely on these standard interfaces being available on every POSIX system. If your program uses the standard interfaces, it can operate on all POSIX systems.

Porting across non-standard systems is more work, as the system interfaces e.g. for multithreading or networking are different.

What other operating systems besides Unix is POSIX compatible with?

First, POSIX is a set of standards so depending on which one you are talking about, you'll find more or less compatible OSes.

Second, any OS complying with the POSIX set of interfaces might be allowed to name itself UNIX so strictly speaking, there can be no POSIX compatible non Unix OS.

The ambiguity comes to the fact Unix is used to name two different things. The first one is the family of OSes having their roots in the original AT&T Unix source code. The second acceptation is any OS which share the same set of interfaces defined by POSIX. Gnu/Linux OSes belong to the latter group.

Anyway, there are only two POSIX compliant OSes (i.e. certified to be compliant) not belonging to the Unix family, QNX and OS X (although the latter shares some code with BSD which has its root in the original Unix).

There are much more compatible still not strictly compliant OSes around. Cygwin, SFU and similar layers are providing a subset of POSIX compatible APIs to Windows. Other non Unix like ones are VxWorks, z/OS, OpenVMS.

For a complete list, have a look to https://en.wikipedia.org/wiki/POSIX#POSIX-oriented_operating_systems

What is glibc and POSIX exactly?

POSIX is a computer standard which is used to standardize operating-systems. Otherwise operating-systems would all be disparate and there wouldn't be any common things between them (a bit like what Microsoft does with Windows). An open standard (unlike Windows) makes computing more accessible and more affordable in some complex ways. Today, you could think that Linux is in some ways being a non-profit organization which promotes open source computing and free/affordable computing. Linux's websites are mostly in the .org as they are organisms which promote the open computing effort.

UNIX in the meantime is an operating-system which is POSIX compliant.

Since glibc works on Linux and Linux is very UNIX-like (see https://www.quora.com/Is-Linux-compatible-with-UNIX), then glibc should work on UNIX systems. Since UNIX is POSIX compliant (see https://linuxhint.com/is_linux_posix_compliant/), then Linux is mostly POSIX compliant.

For how all that relates you can look at my answer on cs.stackexchange.com here https://cs.stackexchange.com/questions/136298/how-are-kernels-and-operating-systems-in-general-written-in-c/136330#136330.

When you write a C app on Linux, you include headers from glibc to use the standard functions like malloc, fork etc. When you compile your app, you either compile it statically or dynamically. When you compile it statically, you include all the kernel code in the executable like mmap's code. Basically, when mmap is called from your main function, the CPU jumps to the function which is mapped in virtual memory. Where it "stops" including the code, is when you jump to kernel code using int 0x80 on older x86 32 bits processors. I don't know about the system call convention for x86-64 honestly. It is probably similar. When your code calls int 0x80 on x86, it interrupts the CPU and it jumps to shared-by-all-processes kernel code. This kernel code cannot be included in your executable because it is interrupt code. So mmap is included in your executable up until the system call. The rest of the work is done in the interrupt handler and then returns to mmap which now has the new address of the allocated memory chunk. mmap then returns to the glibc caller which, like you said, is a wrapper around kernel code calls. When you link dynamically, it is the same except linking happens just before runtime.

POSIX relates to glibc in that POSIX defines the standard API which is going to be called by glibc to implement the C convention. It is really a convention over a convention. The C convention is another convention. It says: if you write this then this should be the result after running the program. Glibc is really looking to implement the C convention but on POSIX compliant systems like Linux.

In the meantime, Python/Ruby etc. are higher level languages mostly written in lower level languages like C++/C. The Python program which runs your python commands is written in C and compiled. Then you write a Python program which is then interpreted during runtime by the C program. There really is nothing magical. It is just a convention over a convention over a convention. POSIX implements the standard for system calls that glibc uses to implement the C convention that Python uses to implement the Python shell which interprets your Python programs at runtime.

What is the relationship between POSIX and the C language?

POSIX is not a specification for a language, it is a specification for an operating system, just one part of which is the wider C library specification and additional restrictions on to how the C language itself needs to be implemented on such operating systems.

There are many popular cross-platform libraries. One popular library that concerns the areas that the POSIX C specification is mostly concerned with is the Apache Portable Runtime:

The mission of the Apache Portable Runtime (APR) project is to create and maintain software libraries that provide a predictable and consistent interface to underlying platform-specific implementations. The primary goal is to provide an API to which software developers may code and be assured of predictable if not identical behaviour regardless of the platform on which their software is built, relieving them of the need to code special-case conditions to work around or take advantage of platform-specific deficiencies or features.

APR includes things like the sockets and threads and processes and can be used to compile the same application for various operating systems - many unix-like ones and Windows - with minimal changes.

How can I determine if the operating system is POSIX in C?

The Single UNIX Specification requires the existence of unistd.h, which can tell you the POSIX version (via the _POSIX_VERSION macro).

But how can you include unistd.h if you don't know yet that you are in fact compiling on a UNIX?

That is where this GCC document comes handy. According to it, testing for the presence, or evaluation-to-true of __unix__ should tell you that the system is a UNIX. So:

#ifdef __unix__
/* Yes it is a UNIX because __unix__ is defined.  */

#include <unistd.h>

/* You can find out the version with _POSIX_VERSION.
..
..  */

#endif

__unix__ is not defined on Mac OS X, so to account for that, you could instead do:

#if defined (__unix__) || (defined (__APPLE__) && defined (__MACH__))

To get a list of system specific predefined macros on your system, you may execute:

cpp -dM /dev/null

For example, my GNU/Linux system also additionally defines __linux__ and __gnu_linux__ apart from __unix__ and a bunch of other stuff.

---

Another useful document that you must look at is this Wiki.

It goes on to present a way of detecting the presence and version of POSIX in a way similar to the one I described above.

---

EDIT: Since you really want to do all this because you want to decide which directory separator to use, look at this URL. It says:

Note File I/O functions in the Windows API convert "/" to "\" as part
of converting the name to an NT-style name, except when using the
"\?\" prefix as detailed in the following sections.

I don't program on Windows, or know much anything about it, so I can't say I've banked on this.

what's the meaning of 'I' in S_IRUSR

The naming is historic ... dating back to the very earliest days of UNIX. The "S" is for STAT, the "I" for INODE (a term not really used in POSIX itself outside Rationale), the "R" for READ and the "USR" for USER.

Inodes do get a few mentions, and the stat structure also includes "st_ino", which the standard describes as the "File Serial Number". In many POSIX implementations, an inode is a data structure containing all the meta-data for the file (much of which is what is read by the stat() call).

(From Wikipedia:) The reason for designating these as "i" nodes is unknown. When asked, Unix pioneer Dennis Ritchie replied:

In truth, I don't know either. It was just a term that we started to
use. "Index" is my best guess, because of the slightly unusual file
system structure that stored the access information of files as a flat
array on the disk, with all the hierarchical directory information
living aside from this. Thus the i-number is an index in this array,
the i-node is the selected element of the array.

(The "i-" notation was used in the 1st edition manual; its hyphen was gradually dropped.)

---

Related Topics