[illumos-Developer] BSD iconv (was Closed-bin accords of the OpenSolaris conference... )

[Garrett D'Amore]

On Tue, 2010-08-10 at 22:26 +0200, Joerg Schilling wrote:
> "Garrett D'Amore" <garrett at damore.org> wrote:
> 
> > This is great news.  I would have *preferred* to pick up a FreeBSD
> > implementation, but it looked like FreeBSD's version had staganted to
> > the point of being replaced with GNU iconv.  Which is not acceptable to
> > me for a variety of reasons.
> >
> > If we can use a FreeBSD implementation, it will help a *lot*.
> 
> Our problem is that we have iconv_open(), iconv_close() and iconv()
> in libc and that we miss the iconv program and various loadable libraries
> from /usr/lib/iconv/
> 
> > Joerg, would you be willing to take a look at this?  If the code looks
> > basically usable and free of major bugs, and like it might be
> > maintainable (or someone in this group wants to step up to help with
> > maintenance), then I'd say this is a way forward.
> 
> The program iconv from *BSD is really simple, but it depends on non-standard 
> extensions to the iconv_open()/iconv_close()/iconv() implementation.
> 
> > I'm not a big fan of the pluggable shared library that Solaris has for
> > this stuff.
> 
> I am not sure what you are talking about. If you are talking about the plugins 
> for various codesets, then it may have advantages. Our problem is that we miss
> these plugins. I should note that the function iconv() is somehow connected to 
> various mb* functions.

May have advantages yes.  But the problem is that there are non-public
API dependencies, and as you noted, we lack the code.

> 
> Our problem is that most of the working code is not inside libc but inside the 
> loadable libraries that we don't have.

Right.

> 
> It seems that we need to decide whether we partly need to give up binary 
> compatibility.

I don't care about iconv or tr, but I *do* care about normal binaries
that are delivered separately.  Programs that are part of the ON
consolidation need not have 100% compatibility, as long as we provide
fully compatible replacements.  Hopefully this makes sense.

> 
> It is obvious that we most likely will never be able to run a tr(1) or iconv(1) 
> binary from Snorcle Solaris. In order to decide how to proceed, we need to know
> which non-hidden interfaces from Snorcle Solaris have to be called "officially
> supported interfaces" and which not.

Right.

> 
> Even if we only like to support the same code-set paris for iconv -f xxx -t yyy, 
> we may need to put a lot of effort into internationalization.

Yes, this gets challenging.

I'm not sure what the best way forward is.  I'm open to suggestions.

	- Garrett
> 
> Jörg
>