View source for POSIX

"POSIX" may more-or-less mistakenly refer to...
* [[Pthreads]], the POSIX threading API (aka POSIX.1c prior to POSIX.1-1997)
* [[Linux APIs]], which partially comply with POSIX
* [[FreeBSD APIs]], which partially comply with POSIX
* [[Shell]], which implements a portion of POSIX
This page is about the "Systems Interfaces and Headers" defined in POSIX.1-2017 (aka IEEE Std 1003.1-2017 (Revision of IEEE Std 1003.1-2008) - IEEE Standard for Information Technology—Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7) APIs. Note that POSIX.1-2017 is equivalent to POSIX.1-2008 plus its two Technical Corrigenda.

==File descriptors==
* <tt>pread(2)</tt> and <tt>pwrite(2)</tt> allow <tt>read(2)</tt>- and <tt>write(2)</tt>-like behavior on a file descriptor from a specified offset, without updating the offset. This allows for the atomic equivalent of an <tt>lseek(2)</tt> and an I/O, particularly useful when multiple threads are working with the same file descriptor (since file descriptor offset is shared across the process). Linux 2.1.69, glibc 2.1, SVR4, POSIX.1-2001.
* The <tt>openat(2)</tt> system call can <tt>open(2)</tt> a file relative to an open directory provided as the first argument. As the man page says:
<pre>       openat() and other similar system calls suffixed "at" are supported for
       two reasons.

       First,  openat()  allows  an  application to avoid race conditions that
       could occur when using open(2) to open files in directories other  than
       the  current  working directory.  These race conditions result from the
       fact that some component of the directory prefix given to open(2) could
       be  changed  in  parallel  with the call to open(2).  Such races can be
       avoided by opening a file descriptor for the target directory, and then
       specifying that file descriptor as the dirfd argument of openat().

       Second,  openat()  allows  the  implementation of a per-thread "current
       working directory", via file descriptor(s) maintained by  the  applica‐
       tion.   (This functionality can also be obtained by tricks based on the
       use of /proc/self/fd/dirfd, but less efficiently.)</pre>Linux 2.6.16, glibc 2.4, FreeBSD 8.0, POSIX.1-2008.

==File handles==
* <tt>fileno(3)</tt> extracts the file descriptor from a [[ISO C|C]] <tt>FILE*</tt>. This will fail if <tt>FILE*</tt> is not associated with a descriptor. Examples include <tt>stdout</tt> and <tt>stderr</tt> in Microsoft Windows applications without a connected console, and a handle opened with POSIX's <tt>fmemopen(3)</tt> or <tt>open_memstream(3)</tt>.
* <tt>fmemopen(3)</tt> creates a <tt>FILE*</tt> handle around a user-supplied buffer, enforcing <tt>mode</tt> similar to <tt>fopen(3)</tt>. If <tt>NULL</tt> is supplied, <tt>fmemopen(3)</tt> will attempt to allocate a buffer of the specified size. Using append mode will place the initial offset at the first zero byte of the buffer, or one past the size of the buffer if no zero bytes are found (I assume this only applies when the buffer is provided externally, rather than internally allocated?). Writing past the size of the buffer will result in an error.
** The glibc implementation of this function, first specified by POSIX.1-2008, has changed over the years, and required several bugfixes.
** The API does not provide any means of getting a pointer to the buffer.
** The append behavior implies an O(size) scan for a zero byte.