Why does iconv function need a non-constant inbuffer?

In the iconv document , the synopsis of the function is as follows:

#include <iconv.h> size_t iconv (iconv_t cd, const char* * inbuf, size_t * inbytesleft, char* * outbuf, size_t * outbytesleft); 

But, when I check iconv.h on my system, the synopsis of the function is this:

 extern size_t iconv (iconv_t __cd, char **__restirct __inbuf, size_t *__restrict __inbytesleft, char **__restirct __outbuf, size_t *__restrict __outbytesleft); 

In these two synonyms of functions, one is const char **, and the other is only char **.

Why is the syntax of the function in the document different from the one on my system? And why does the iconv function need a non-constant inbuffer?

The version of my g ++ is 6.3.0.

+5
source share
2 answers

The problem with iconv() is that it is not part of the C standard, but is specified in two different standards. One of them is POSIX-1.2008 :

 #include <iconv.h> size_t iconv(iconv_t cd, char **restrict inbuf, size_t *restrict inbytesleft, char **restrict outbuf, size_t *restrict outbytesleft); 

Another SUSv2 :

 #include <iconv.h> size_t iconv(iconv_t cd, const char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft); 

They differ in const n **inbuf , so if you want to remain portable between both standards, you will unfortunately need to pass a non-constant **inbuf .

Edit:. Since this is a double pointer, the problem is even worse, see my answer here . In a nutshell, these specifications are incompatible in any direction ...


What you linked as โ€œdocument of iconvโ€ is the GNU libiconv documentation, which is intended to be used on platforms that iconv() does not initially provide โ€” this obviously follows SUSv2 .

The header file that you find on your system refers to glibc , your C platform library and this implementation complies with the POSIX-1.2008 specification .

+5
source

const char * * inbuf, vs. char ** __ restirct __inbuf, I think. - Suraw Gosh

valid - the constraint tells the compiler that the pointer object will not change. This announcement was made in such a way as to provide better optimization of the generated code.

Using a constraint can actually result in worse code at a higher level of optimization.

https://godbolt.org/g/uhfVCe

+1
source

Source: https://habr.com/ru/post/1271331/


All Articles