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