FGETWC(3POSIX)

🌸 fgetwc β€” get a wide-character code from a stream 🌸

okay bestie, welcome to fgetwc(3POSIX) πŸ’– this one lives in the POSIX Programmer's Manual and it's lowkey one of the most used little functions in the whole wide-char world. let's get into it ✨


🫢 PROLOG

So like, heads up before we even start: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ β€” so if you're on Linux, bestie, go consult the corresponding Linux manual page for the deets on Linux behavior. Orrr the interface might not even be implemented on Linux at all. vibe check your platform first πŸ’…


πŸ‘‘ NAME

fgetwc β€” get a wide-character code from a stream


✨ SYNOPSIS

#include <stdio.h>
#include <wchar.h>

wint_t fgetwc(FILE *stream);

πŸ’œ DESCRIPTION

The functionality described on this reference page is aligned with the ISO C standard. And listen β€” any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1‐2017 defers to the ISO C standard. ISO C is the main character here, we're just hyping her up πŸŽ€

The fgetwc() function shall obtain the next character (if present) from the input stream pointed to by stream, convert that to the corresponding wide-character code, and advance the associated file position indicator for the stream (if defined). so it's literally: grab a char, glow it up into a wide char, and scoot the file position forward. iconic behavior ✨

⚠️ If an error occurs, the resulting value of the file position indicator for the stream is unspecified. so like... don't count on it, bestie 😭

The fgetwc() function may mark the last data access timestamp of the file associated with stream for update. And the last data access timestamp shall be marked for update by the first successful execution of fgetwc(), fgetws(), fwscanf(), getwc(), getwchar(), vfwscanf(), vwscanf(), or wscanf() using stream that returns data not supplied by a prior call to ungetwc(). yeah that's a whole squad of functions sharing the timestamp duties 🫢

And the best part: the fgetwc() function shall not change the setting of errno if successful. no drama on a good day πŸ’…


πŸ”₯ RETURN VALUE

Upon successful completion, the fgetwc() function shall return the wide-character code of the character read from the input stream pointed to by stream, converted to a type wint_t. slay πŸ’–

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 fgetwc() shall return WEOF.

If a read error occurs, the error indicator for the stream shall be set, fgetwc() shall return WEOF, and shall set errno to indicate the error.

If an encoding error occurs, the error indicator for the stream shall be set, fgetwc() shall return WEOF, and shall set errno to indicate the error.

so like: success = the char, sadness = WEOF, and errno tells you why the sadness happened. always check errno, periodt πŸ‘‘


πŸ’€ ERRORS

The fgetwc() function shall fail if data needs to be read and:

  • EAGAIN β€” The O_NONBLOCK flag is set for the file descriptor underlying stream and the thread would be delayed in the fgetwc() operation. like she's busy, try later bestie πŸ™ˆ
  • EBADF β€” The file descriptor underlying stream is not a valid file descriptor open for reading. not a real fd, or not opened for reading. invalid, honestly πŸ’€
  • EILSEQ β€” The data obtained from the input stream does not form a valid character. the bytes said something unhinged and we can't decode it 😭
  • EINTR β€” The read operation was terminated due to the receipt of a signal, and no data was transferred. a signal interrupted, nothing came through 🫢
  • 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 blocking SIGTTIN or the process is ignoring SIGTTIN or the process group of the process is orphaned. This error may also be generated for implementation-defined reasons. yeah that's a long one but it's all here, no cap πŸ”₯
  • 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. you tried to read past the vibe limit ⭐

The fgetwc() function may fail if:

  • ENOMEM β€” Insufficient storage space is available. no memory, no service πŸ˜”
  • ENXIO β€” A request was made of a nonexistent device, or the request was outside the capabilities of the device. asking a device for something it literally cannot do πŸ¦‹
✨ The following sections are informative.

🌈 EXAMPLES

None. (she said "figure it out bestie" πŸ’…)


πŸŽ€ APPLICATION USAGE

The ferror() or feof() functions must be used to distinguish between an error condition and an end-of-file condition. this is the number one mistake people make and it's giving chaos β€” WEOF alone cannot tell you which one happened, so check ferror() and feof(), fr fr πŸ’–


🧚 RATIONALE

None.


⭐ FUTURE DIRECTIONS

None.


πŸ’œ SEE ALSO

  • Section 2.5, Standard I/O Streams
  • feof()
  • ferror()
  • fopen()

The Base Definitions volume of POSIX.1‐2017:

  • <stdio.h>
  • <wchar.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 cutie dropped back in 2017 from IEEE/The Open Group, filed under FGETWC(3POSIX) β€” go forth and read your wide chars responsibly, mwah πŸ’‹βœ¨