[openbeos] Re: suggestions: iconv.h, libiconv, and iconv

On Wed, 30 Jul 2003 22:42:03 -0700 PDT "Andrew Bachmann" <
shatty@xxxxxxxxxxxxx> wrote:
[...]
> Anyway, I was thinking LGPL and all that and I also realized "hey, 
> FreeBSD has an iconv 
> implementation! let's go check that out".  So I trucked over to 
> freebsd and grabbed their "iconv" 
> package.  I downloaded it and went to build, and what the heck is 
> going on?  The makefiles are 
> all written in some gobbledygook makefile language that gnumake don't 
> grok. (and neither do I)  
> So that was quite annoying.  I worked at it for a bit converting the 
> makefile to jamfiles.  In the 
> midst I ran into another nasty.  FreeBSD's build system uses perl 
> scripts to autogenerate the 
> tables.  (ugg)

There shouldn't be a problem with using perl in our build system, if 
needed.

> At this point I decided to go back to the gnu one since I at least 
> got that fully built.  That's when I 
> noticed another nasty. (is there no end to them?)  The GNU version of 
> iconv.h declares the 
> function iconv's second argument as a const char ** instead of a char 
> **.  You wouldn't think it'd 
> be much of a deal to pass a char ** into a const char ** function but 
> at least my compiler doesn't 
> like it.  It says: "passing `char **' as argument 2 of `iconv' adds 
> cv-quals without intervening 
> `const'".  Yuck! So, although the gnu header has a sort of 
> enlightened argument list in that it 
> simply promises to less damage, the compile fails.

Yep, for good reason, since otherwise you could cast consts away 
without the compiler noticing it Like:

        char *a;
        char **b = &a;
        const char **c = b;             // nasty code
        const char *d = "Hello!";
        *c = d;
        *a = 0;                                 // here we write to d

That's a bit unfortunate, for in some cases it seems to be a bit too 
strict, but we can't do anything about it (aside from doing a 
const_cast<>).

> So, I'm stuck in what I view to be a poor situation.  Right now we 
> have what I consider to be a 
> perfectly fine, ideal version of iconv.h checked in. (after I added 
> size_t.h anyway)  However, 
> using this header, you can't link to the libiconv.so from gnu. (doh!)  
> If we replaced our perfectly 
> good header with the messy gnu iconv.h then we get a compiler error 
> on (what I think is) posix-
> ok code. (doh!)  Now it seems like the FreeBSD library may be able to 
> save the day.  But to build 
> it requires decyphering freebsd make and also having perl around to 
> run build scripts. (doh!)  
> The FreeBSD iconv also has the second argument const char **, but at 
> least we don't have to link 
> against that header since it properly exports the functions by their 
> rightful names. (as far as I can 
> tell so far since I haven't got it building yet)
> 
> So, I'm quite mystified here.  Can I get some opinions or 
> observations?  In my opinion we should 
> stick to the posix definition of iconv's argument list, and as far as 
> I can tell that means no const.  
> We also should publish the symbol from our libiconv.so as iconv, and 
> not as libiconv.  Right now I 
> see three options:
> 
> 1. Build the so-called "plugin" version of gnu libiconv.so [this 
> version publishes the API as 
> iconv_open and not libiconv_open], and publish it as libiconv.so.  
> This is possible by modifying a 
> makefile slightly and manually requesting the plugin version.

We can as well build the `normal' version and write the <iconv.h> 
functions as simple wrappers for the GNU ones.

> 2. Decypher the FreeBSD build system and use their libiconv.so.  This 
> may involve either 
> checking in perl-generated files, or requiring perl to build.  In any 
> case it will require some 
> effort and would probably be best done by someone familiar with their 
> build system or at least 
> with access to a box that has freebsd installed.  A rather 
> significant drawback of this approach in 
> my opinion is that it may be difficult to update our "version" when 
> the FreeBSD one gets 
> updated.
> 3. Do something else.

1. seems to be the option involving the least work. So, I would say, 
let's go for that. I would mind either of the alternatives concerning 
integrating the library into libroot or libtextencoding or have it 
stand alone.

CU, Ingo

Other related posts: