Check out my first novel, midnight's simulacra!

POSIX: Difference between revisions

From dankwiki
No edit summary
No edit summary
Line 13: Line 13:
** The glibc implementation of this function, first specified by POSIX.1-2008, has changed over the years, and required several bugfixes.
** 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 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.

Revision as of 06:13, 5 January 2023

"POSIX" may more-or-less mistakenly refer to...

  • Pthreads, the POSIX threading API aka POSIX.1c
  • Linux APIs, which implement a portion of POSIX
  • FreeBSD APIs, which implement 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

  • 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.

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.