Check out my first novel, midnight's simulacra!
POSIX: Difference between revisions
From dankwiki
(POSIX disambiguation page) |
|||
(3 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
POSIX may refer to... | "POSIX" may more-or-less mistakenly refer to... | ||
* [[Pthreads]], the POSIX threading API | * [[Pthreads]], the POSIX threading API (aka POSIX.1c prior to POSIX.1-1997) | ||
* [[Linux APIs]], which | * [[Linux APIs]], which partially comply with POSIX | ||
* [[FreeBSD APIs]], which | * [[FreeBSD APIs]], which partially comply with POSIX | ||
* [[Shell]], which implements a portion of 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. |
Latest revision as of 06:27, 5 January 2023
"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
- pread(2) and pwrite(2) allow read(2)- and write(2)-like behavior on a file descriptor from a specified offset, without updating the offset. This allows for the atomic equivalent of an lseek(2) 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 openat(2) system call can open(2) a file relative to an open directory provided as the first argument. As the man page says:
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.)
Linux 2.6.16, glibc 2.4, FreeBSD 8.0, POSIX.1-2008.
File handles
- fileno(3) extracts the file descriptor from a C FILE*. This will fail if FILE* is not associated with a descriptor. Examples include stdout and stderr in Microsoft Windows applications without a connected console, and a handle opened with POSIX's fmemopen(3) or open_memstream(3).
- fmemopen(3) creates a FILE* handle around a user-supplied buffer, enforcing mode similar to fopen(3). If NULL is supplied, fmemopen(3) 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.