At 02:48 PM 8/20/01 -0500, David Mandelin wrote:
>Nope. The new version still requires implicitly converting 'char **' to
>'const char **'. I don't think anything like this is going to work. (To
>work on conforming-compiler/iconv-without-const, you need to cast away
>the const. If you put ICONV_CONST in the cast, gcc3 is unhappy. If you
>don't, on a conforming compiler, you'll need to cast the const back in.
>But then that won't work if you have gcc3/iconv-without-const.)
>
>ICONV_CONST char ** buf = const_cast<char **>(inbuf);
Folks,
By all means feel free to keep working to come up with the appropriate macro
magic to keep all these compiler/iconv permutations happy. (I don't have
much patience for this, but I admire those of you who do.)
However, my understanding is that we're stuck in this mess because we're
trying to find a compile-time way to support all three of the following:
A. libiconv (API #1)
B. stock iconv implementations which share API #1
C. stock iconv implementations which ship with a different API
Call me an ignorant heathen, but here's my modest proposal:
We can always decide that one of those APIs is *just plain busted*
and refuse to support it (on those platforms).
I don't know *or* care what rationale we use to decide which API is busted.
Worst case, one's an ANSI or POSIX standard, and the other's technically a
better idea. I still don't care. Just pick one.
Are all of the following alternatives unacceptable?
- Decide that #2 is the "busted" API, fix the build system to require
building a peer libiconv on those platforms (case C), and we're done.
- Decide that #1 is busted, fork #1 to match #2, and require libiconv
as a peer on B.
- Finally, if building libiconv as a peer on only some Unix platforms
is too complex, then we could just forget about supporting B or C and
just always require libiconv.
Now back to our regularly-scheduled ICONV_CONST party, already in progress.
:-)
Paul,
motto -- standards save time & hassle
