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 seterrnoto[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
inbufshall be updated to point to the byte following the last byte successfully used in the conversion. - the value pointed to by
inbytesleftshall be decremented to reflect the number of bytes still not converted in the input buffer. - the variable pointed to by
outbufshall be updated to point to the byte following the last byte of converted output data. - the value pointed to by
outbytesleftshall 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
inbytesleftshall be0. full send, nothing left, slay. - if the input conversion is stopped due to any conditions mentioned above, the value pointed to by
inbytesleftshall be non-zero anderrnoshall be set to indicate the condition. leftover bytes = something went sideways, checkerrno. - if an error occurs,
iconv()shall return(size_t)-1and seterrnoto 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β thecdargument 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> π
π 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, we ate and left no crumbs π
β¨ this iconv page is from IEEE/The Open Group, 2017, tagged ICONV(3POSIX) β literally iconic, periodt ππ¦π
π¦ 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