Ryan Schmidt wrote:
I have a problem with iconv.h from libiconv 1.12 and the
fact that it differs depending on whether it's installed on Mac OS X
10.4 or 10.5.
On Mac OS X 10.4 with Xcode 2.4.1 (or Xcode 2.5), and libiconv 1.12
installed by MacPorts, iconv.h defines the iconv() function this way:
extern size_t iconv (iconv_t cd, const char* * inbuf, size_t
*inbytesleft, char* * outbuf, size_t *outbytesleft);
On Mac OS X 10.5 with Xcode 3.0 (or Xcode 3.1 from iPhone SDK beta
6), the same version of libiconv defines the second parameter of
iconv
() differently:
extern size_t iconv (iconv_t cd, char* * inbuf, size_t *inbytesleft,
char* * outbuf, size_t *outbytesleft);
libiconv, installed from source, uses 'const' or not here,
depending whether
the system header uses 'const' or not. And in MacOS X 10.5, Apple
changed
their headers for POSIX compliance (so as to get the UNIX 2003
branding).
And POSIX happens to specify 'char **' for iconv's inbuf parameter.
See the diff between the 10.4 and 10.5 headers at the end of this
mail.
This causes problems for software that wants to work on both Mac OS X
10.4 and 10.5. See:
http://trac.macports.org/changeset?new=trunk%2Fdports%2Fdevel%2Fice-
cpp%2FPortfile%4037235&old=trunk%2Fdports%2Fdevel%2Fice-cpp%
2FPortfile
%4037182
And:
http://trac.macports.org/ticket/15297
The developer of the pure language feels this is a bug in libiconv.
This incompatible change is under Apple's responsibility, since
they changed
the system header.
You can blame libiconv for having used 'const' by default in the
past, but
this is "corrected" in libiconv 1.12.
As a way out, the iconv.m4 macro from gnulib
<http://www.gnu.org/software/gnulib/MODULES.html#module=iconv>
detects the presence or absence of 'const' and defines ICONV_CONST
accordingly. So that you can cast the argument to (ICONV_CONST char
**)
and be safe in all cases. It is documented here:
<http://www.gnu.org/software/gettext/manual/html_node/
AM_005fICONV.html>