FGETC(3POSIX)
π¦ FGETC β get a byte from a stream π¦
okay bestie, welcome to the POSIX Programmer's Manual π before we get into it, a lil heads up: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (so like, go check the corresponding Linux manual page for the tea on Linux behavior), or honestly the interface may not even be implemented on Linux. π
β¨ NAME β¨
fgetc β get a byte from a stream. that's it. that's the whole vibe. one byte. from a stream. π
πΈ SYNOPSIS πΈ
#include <stdio.h>
int fgetc(FILE *stream);
π DESCRIPTION π
so the functionality on this reference page is aligned with the ISO C standard. If there's any conflict between what's required here and the ISO C standard, that conflict is unintentional, okay, nobody's fighting. This volume of POSIX.1β2017 defers to the ISO C standard. periodt.
If the end-of-file indicator for the input stream pointed to by stream is not set and a next byte is present, the fgetc() function shall obtain the next byte as an unsigned char converted to an int, from the input stream pointed to by stream, and advance the associated file position indicator for the stream (if defined). Since fgetc() operates on bytes, reading a character consisting of multiple bytes (or ``a multi-byte character'') may require multiple calls to fgetc(). yes bestie, one byte at a time, it's giving patience, it's giving little sips π
The fgetc() function may mark the last data access timestamp of the file associated with stream for update. The last data access timestamp shall be marked for update by the first successful execution of fgetc(), fgets(), fread(), fscanf(), getc(), getchar(), getdelim(), getline(), gets(), or scanf() using stream that returns data not supplied by a prior call to ungetc(). so many icons in that list fr fr π
π₯ RETURN VALUE π₯
Upon successful completion, fgetc() shall return the next byte from the input stream pointed to by stream. If the end-of-file indicator for the stream is set, or if the stream is at end-of-file, the end-of-file indicator for the stream shall be set and fgetc() shall return EOF. If a read error occurs, the error indicator for the stream shall be set, fgetc() shall return EOF, and shall set errno to indicate the error. π no cap, that EOF hits different
π ERRORS π
The fgetc() function shall fail if data needs to be read and:
EAGAINβ TheO_NONBLOCKflag is set for the file descriptor underlying stream and the thread would be delayed in thefgetc()operation. lowkey it said "not right now bestie" πEBADFβ The file descriptor underlying stream is not a valid file descriptor open for reading. π«EINTRβ The read operation was terminated due to the receipt of a signal, and no data was transferred.EIOβ A physical I/O error has occurred, or the process is in a background process group attempting to read from its controlling terminal, and either the calling thread is blockingSIGTTINor the process is ignoringSIGTTINor the process group of the process is orphaned. This error may also be generated for implementation-defined reasons. πEOVERFLOWβ The file is a regular file and an attempt was made to read at or beyond the offset maximum associated with the corresponding stream.
The fgetc() function may fail if:
ENOMEMβ Insufficient storage space is available.ENXIOβ A request was made of a nonexistent device, or the request was outside the capabilities of the device.
The following sections are informative. (translation: the juicy part is over, this is bonus content β¨)
π EXAMPLES π
None. bestie there is literally nothing here, the examples are not example-ing π
π«Ά APPLICATION USAGE π«Ά
If the integer value returned by fgetc() is stored into a variable of type char and then compared against the integer constant EOF, the comparison may never succeed, because sign-extension of a variable of type char on widening to integer is implementation-defined. so like... do NOT do that, that's the trap, that's the jumpscare π¨
The ferror() or feof() functions must be used to distinguish between an error condition and an end-of-file condition. you literally cannot tell them apart otherwise, they're twins, you need the receipts π
π RATIONALE π
None. iconic of it honestly
π FUTURE DIRECTIONS π
None.
π SEE ALSO π
- Section 2.5, Standard I/O Streams
feof()ferror()fgets()fread()fscanf()getchar()getc()gets()ungetc()
The Base Definitions volume of POSIX.1β2017, <stdio.h>
π COPYRIGHT π
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 came from IEEE/The Open Group, dated 2017, and it's the FGETC(3POSIX) page β now go read exactly one byte at a time and slay β¨π
π¦ where this page comes from
- debian bookworm: manpages-posix-dev 2017a-2 Β· Other
- debian trixie: manpages-posix-dev 2017a-2 Β· Other
- ubuntu jammy: manpages-posix-dev 2017a-2 Β· Other
- ubuntu noble: manpages-posix-dev 2017a-2 Β· Other
- ubuntu resolute: manpages-posix-dev 2017a-2build1 Β· Other
- ubuntu stonking: manpages-posix-dev 2017a-2.1 Β· Other
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms