FSEEK(3P)

πŸ’… FSEEK(3P) πŸ’…

ok so this one is from the POSIX Programmer's Manual (yes, the fancy IEEE/The Open Group one, FSEEK(3P) bestie, we're in the 3P section) and it's all about fseek and fseeko. Buckle up, it's giving "I know exactly where I'm going" energy.


✨ PROLOG ✨

Real talk before we start: this page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ β€” so if you're on Linux, go check the corresponding Linux manual page for the deets on Linux behavior. Or, plot twist, the interface might not even be implemented on Linux at all. πŸ™ˆ


🌸 NAME 🌸

fseek, fseeko β€” reposition a file-position indicator in a stream


πŸŽ€ SYNOPSIS πŸŽ€

#include <stdio.h>

int fseek(FILE *stream, long offset, int whence);
int fseeko(FILE *stream, off_t offset, int whence);

πŸ¦‹ DESCRIPTION πŸ¦‹

So the tea is: everything described on this page is aligned with the ISO C standard. If anything here conflicts with the ISO C standard, that's unintentional, not a vibe. And this volume of POSIX.1‐2017 defers to the ISO C standard. Periodt.

The fseek() function shall set the file-position indicator for the stream pointed to by stream. And if a read or write error happens? The error indicator for the stream gets set and fseek() fails. Not the glow-up we wanted. 😭

Here's how the new position works, bestie β€” it's measured in bytes from the beginning of the file, and you get it by adding offset to the position specified by whence. And whence says which point we're starting from:

  • SEEK_SET β€” the beginning of the file
  • SEEK_CUR β€” the current value of the file-position indicator
  • SEEK_END β€” end-of-file

Now, if the stream is gonna be used with wide-character input/output functions, then the application shall ensure that offset is either 0 or a value returned by an earlier call to ftell() on the same stream, and that whence is SEEK_SET. That's the rule, no cap.

A successful call to fseek() shall clear the end-of-file indicator for the stream and undo any effects of ungetc() and ungetwc() on that same stream. Obsessed. And after an fseek() call, the next operation on an update stream may be either input or output β€” your choice, main character.

If the most recent operation on a given stream β€” other than ftell() β€” is fflush(), then the file offset in the underlying open file description shall be adjusted to reflect the location specified by fseek(). iykyk.

fseek() shall allow the file-position indicator to be set beyond the end of existing data in the file. And if data is later written at that point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap. So the gap is just... zeros until you fill it. Iconic, honestly.

The behavior of fseek() on devices which are incapable of seeking is implementation-defined. And the value of the file offset associated with such a device is undefined. πŸ’€ So like, don't count on it.

If the stream is writable and buffered data had not been written to the underlying file, fseek() shall cause the unwritten data to be written to the file, and shall mark the last data modification and last file status change timestamps of the file for update. Slay.

In a locale with state-dependent encoding, whether fseek() restores the stream's shift state is implementation-defined. Just so you know.

And finally, the moment you've been waiting for: fseeko() shall be equivalent to the fseek() function, except that the offset argument is of type off_t. That's literally the whole difference. πŸ’–


⭐ RETURN VALUE ⭐

  • The fseek() and fseeko() functions shall return 0 if they succeed. 🫢
  • Otherwise, they shall return -1 and set errno to indicate the error.

πŸ”₯ ERRORS πŸ”₯

The fseek() and fseeko() functions shall fail if β€” either the stream is unbuffered, or the stream's buffer needed to be flushed, and the call to fseek() or fseeko() causes an underlying lseek() or write() to be invoked β€” and:

  • EAGAIN β€” The O_NONBLOCK flag is set for the file descriptor and the thread would be delayed in the write operation.
  • EBADF β€” The file descriptor underlying the stream file is not open for writing, or the stream's buffer needed to be flushed and the file is not open.
  • EFBIG β€” An attempt was made to write a file that exceeds the maximum file size.
  • EFBIG β€” An attempt was made to write a file that exceeds the file size limit of the process.
  • EFBIG β€” The file is a regular file and an attempt was made to write at or beyond the offset maximum associated with the corresponding stream.
  • EINTR β€” The write operation was terminated due to the receipt of a signal, and no data was transferred.
  • EINVAL β€” The whence argument is invalid. The resulting file-position indicator would be set to a negative value.
  • EIO β€” A physical I/O error has occurred, or the process is a member of a background process group attempting to perform a write() to its controlling terminal, TOSTOP is set, the calling thread is not blocking SIGTTOU, the process is not ignoring SIGTTOU, and the process group of the process is orphaned. This error may also be returned under implementation-defined conditions.
  • ENOSPC β€” There was no free space remaining on the device containing the file.
  • EOVERFLOW β€” For fseek(), the resulting file offset would be a value which cannot be represented correctly in an object of type long.
  • EOVERFLOW β€” For fseeko(), the resulting file offset would be a value which cannot be represented correctly in an object of type off_t.
  • EPIPE β€” An attempt was made to write to a pipe or FIFO that is not open for reading by any process; a SIGPIPE signal shall also be sent to the thread.
  • ESPIPE β€” The file descriptor underlying stream is associated with a pipe, FIFO, or socket.

The fseek() and fseeko() functions may fail if:

  • ENXIO β€” A request was made of a nonexistent device, or the request was outside the capabilities of the device.
Heads up bestie: the following sections are informative. They're the vibes, not the rules. πŸ’œ

🌈 EXAMPLES 🌈

None.


🧚 APPLICATION USAGE 🧚

None.


πŸ’œ RATIONALE πŸ’œ

None.


🌟 FUTURE DIRECTIONS 🌟

None.


πŸ‘‘ SEE ALSO πŸ‘‘

  • Section 2.5, Standard I/O Streams
  • fopen()
  • fsetpos()
  • ftell()
  • getrlimit()
  • lseek()
  • rewind()
  • ulimit()
  • ungetc()
  • write()
  • The Base Definitions volume of POSIX.1‐2017, <stdio.h>

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .


and that's the whole page, bestie!! πŸŽ€βœ¨ this one was stamped by IEEE/The Open Group in 2017 β€” so yeah, it's giving vintage, it's giving authoritative, it's giving "my parents paid for this standard." go forth and seek responsibly πŸ’…πŸ¦‹πŸ’–

πŸ“¦ where this page comes from