ICONV(3POSIX)

✨ ICONV(3POSIX) ✨

okay bestie, gather round, we're doing a POSIX Programmer's Manual page today πŸ’– this one is iconv from the POSIX Programmer's Manual, and before we even get into it β€” quick heads up, this page is part of the POSIX Programmer's Manual, so the Linux implementation of this interface may be different (peep the corresponding Linux manual page for the deets on Linux behavior), or honestly the interface may not even be implemented on Linux at all. no cap. πŸ’€


🌸 NAME 🌸

iconv β€” codeset conversion function πŸ¦‹


✨ SYNOPSIS ✨

#include <iconv.h>

size_t iconv(iconv_t cd, char **restrict inbuf,
    size_t *restrict inbytesleft, char **restrict outbuf,
    size_t *restrict outbytesleft);

πŸ’… DESCRIPTION πŸ’…

okay so the iconv() function shall convert the sequence of characters from one codeset β€” in the array specified by inbuf β€” into a sequence of corresponding characters in another codeset, in the array specified by outbuf. the codesets are the ones specified in the iconv_open() call that returned the conversion descriptor, cd. so like, cd is the whole vibe, it's holding the receipts on which codesets we're converting between πŸŽ€

the inbuf argument points to a variable that points to the first character in the input buffer, and inbytesleft indicates the number of bytes to the end of the buffer to be converted. meanwhile outbuf points to a variable that points to the first available byte in the output buffer, and outbytesleft indicates the number of available bytes to the end of the buffer. yes she's pointer-to-pointer energy, we love a double pointer moment 🫢


πŸ¦‹ state-dependent encodings, the plot twist πŸ¦‹

for state-dependent encodings, the conversion descriptor cd is placed into its initial shift state by a call for which inbuf is a null pointer, or for which inbuf points to a null pointer. when iconv() is called this way, and if outbuf is not a null pointer or a pointer to a null pointer, and outbytesleft points to a positive value, iconv() shall place, into the output buffer, the byte sequence to change the output buffer to its initial shift state. it's giving reset button πŸ”„

🚨 if the output buffer is not large enough to hold the entire reset sequence, iconv() shall fail and set errno to [E2BIG]. so like, size your buffer or catch these errors, bestie.

subsequent calls with inbuf as other than a null pointer or a pointer to a null pointer cause the conversion to take place from the current state of the conversion descriptor. so the state carries over, it remembers, iconic behavior honestly πŸ‘‘


πŸ’– when conversion stops (the drama) πŸ’–

if a sequence of input bytes does not form a valid character in the specified codeset, conversion shall stop after the previous successfully converted character. if the input buffer ends with an incomplete character or shift sequence, conversion shall stop after the previous successfully converted bytes. and if the output buffer is not large enough to hold the entire converted input, conversion shall stop just prior to the input bytes that would cause the output buffer to overflow. it literally refuses to spill the tea beyond the buffer, so respectful 😭

now the receipts get updated:

  • the variable pointed to by inbuf shall be updated to point to the byte following the last byte successfully used in the conversion.
  • the value pointed to by inbytesleft shall be decremented to reflect the number of bytes still not converted in the input buffer.
  • the variable pointed to by outbuf shall be updated to point to the byte following the last byte of converted output data.
  • the value pointed to by outbytesleft shall be decremented to reflect the number of bytes still available in the output buffer.
  • for state-dependent encodings, the conversion descriptor shall be updated to reflect the shift state in effect at the end of the last successfully converted byte sequence. keeping the vibes consistent, periodt πŸ’…

🌈 the substitute-teacher character moment 🌈

if iconv() encounters a character in the input buffer that is valid, but for which an identical character does not exist in the target codeset, iconv() shall perform an implementation-defined conversion on this character. so like, it does something β€” but the "something" is up to the implementation, no cap, we don't make the rules 🧚


πŸ‘‘ RETURN VALUE πŸ‘‘

the iconv() function shall update the variables pointed to by the arguments to reflect the extent of the conversion and return the number of non-identical conversions performed. so if some characters had to get swapped out for the closest match, that count goes up ⭐

  • if the entire string in the input buffer is converted, the value pointed to by inbytesleft shall be 0. full send, nothing left, slay.
  • if the input conversion is stopped due to any conditions mentioned above, the value pointed to by inbytesleft shall be non-zero and errno shall be set to indicate the condition. leftover bytes = something went sideways, check errno.
  • if an error occurs, iconv() shall return (size_t)-1 and set errno to indicate the error. yeah, (size_t)-1, she's not subtle πŸ’€

🚨 ERRORS 🚨

the iconv() function shall fail if:

  • EILSEQ β€” input conversion stopped due to an input byte that does not belong to the input codeset. like girl, that byte is not from around here πŸ™ˆ
  • E2BIG β€” input conversion stopped due to lack of space in the output buffer. not enough room, output buffer said "I'm full bestie" πŸ“
  • EINVAL β€” input conversion stopped due to an incomplete character or shift sequence at the end of the input buffer. it's giving unfinished sentence energy 😭

the iconv() function may fail if:

  • EBADF β€” the cd argument is not a valid open conversion descriptor. you're holding a fake ID, that descriptor isn't real πŸ’…

the following sections are informative. (translation: the juicy spec part is over, but stick around, there's lore πŸŽ€)


🌸 EXAMPLES 🌸

None.

(yeah, none. the examples are on vacation. we're thriving regardless ✨)


πŸ’œ APPLICATION USAGE πŸ’œ

the inbuf argument indirectly points to the memory area which contains the conversion input data. the outbuf argument indirectly points to the memory area which is to contain the result of the conversion. the objects indirectly pointed to by inbuf and outbuf are not restricted to containing data that is directly representable in the ISO C standard language char data type. so like, don't assume it's just cute little chars, okay? 🌈

the type of inbuf and outbuf, char **, does not imply that the objects pointed to are interpreted as null-terminated C strings or arrays of characters. so do NOT treat these like strings, bestie, that's a trap πŸ’€

any interpretation of a byte sequence that represents a character in a given character set encoding scheme is done internally within the codeset converters. for example, the area pointed to indirectly by inbuf and/or outbuf can contain all zero octets that are not interpreted as string terminators but as coded character data according to the respective codeset encoding scheme. zero bytes are just characters here, they're not "the end," they're literally just vibing as data ⭐

the type of the data (char, short, long, and so on) read or stored in the objects is not specified, but may be inferred for both the input and output data by the converters determined by the fromcode and tocode arguments of iconv_open(). the converter is the one deciding what type energy we're on πŸ¦‹


πŸŽ€ bytes are bytes πŸŽ€

regardless of the data type inferred by the converter, the size of the remaining space in both input and output objects (the intbytesleft and outbytesleft arguments) is always measured in bytes.

πŸ“ ngl that's a typo situation in the original β€” it says intbytesleft in that sentence (we're keeping it exactly as written, we don't fix, we preserve πŸ’…) β€” but the point is: always bytes, no matter what type the converter thinks it's dealing with.

🧚 descriptor energy 🧚

for implementations that support the conversion of state-dependent encodings, the conversion descriptor must be able to accurately reflect the shift-state in effect at the end of the last successful conversion. it is not required that the conversion descriptor itself be updated, which would require it to be a pointer type. thus, implementations are free to implement the descriptor as a handle (other than a pointer type) by which the conversion information can be accessed and updated. so cd can be a whole opaque handle situation, not necessarily a pointer β€” the implementation has freedom here, and honestly, respect the flexibility πŸ’…


πŸ”₯ RATIONALE πŸ”₯

None.

(nothing here. the rationale said "no thoughts, head empty" πŸŽ€)


🌈 FUTURE DIRECTIONS 🌈

None.


πŸ’– SEE ALSO πŸ’–

  • iconv_open()
  • iconv_close()
  • mbsrtowcs()

and from the Base Definitions volume of POSIX.1‐2017: <iconv.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, we ate and left no crumbs πŸ’…βœ¨ this iconv page is from IEEE/The Open Group, 2017, tagged ICONV(3POSIX) β€” literally iconic, periodt πŸŽ€πŸ¦‹πŸ’–