[haiku-development] Re: Source-level incompatibility in iconv.h

  • From: Oliver Tappe <zooey@xxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Tue, 28 Oct 2008 12:09:50 +0100

Hi Jérôme,

On 2008-10-27 at 20:29:06 [+0100], Jérôme Duval <jerome.duval@xxxxxxxxx> wrote:
> 
> 2008/10/27 Oliver Tappe <zooey@xxxxxxxxxxxxxxx>:
> > our iconv.h declares the iconv function with this signature:
> >
> >    size_t iconv(iconv_t, char**, size_t *, char**, size_t *);
> >
> > but I think it should rather make use of a const char** for the source
> > buffer, like this:
> >
> >    size_t iconv(iconv_t, const char**, size_t *, char**, size_t *);
> 
> Though the Haiku definition is the one from POSIX:
> http://www.opengroup.org/onlinepubs/009695399/functions/iconv.html

Ah, I have no idea why the standard leaves out the const, though ;-)

Anyway, in the long run it probably makes more sense to stick with the POSIX 
spec.

> > Using a non-const source buffer causes a problem when compiling libiconv on
> > haiku, as that determines whether or not to use a const buffer by looking at
> > the system's iconv.h header. As a result, the libiconv package on 
> > haiku-ports
> > declares the source buffer as non-const.
> > On R5, the iconv.h header didn't exist, which in turn caused the existing
> > libiconv packages for R5 to declare the source buffer as const.
> >
> > With the current setup, any application that uses iconv() would have to
> > explicitly cast away any potential constness of its internal buffers in 
> > order
> > to be able to invoke haiku's iconv().
> 
> It's just the case on any OS, isn't it ?

Yep, and that actually makes it even worse, since I bet there are several 
applications out there which use const_cast to invoke iconv() - if we would add 
const to our declaration, those applications could not be compiled on haiku. 
Bummer!

So I suppose we better just stick with the standard.

cheers,
    Oliver

Other related posts: