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

[Joerg Schilling]

"Garrett D'Amore" <garrett at damore.org> wrote:

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


OK, then let us start with a design discuccion.

We could create iconv_open()/iconv_close()/iconv() stub replacements for libc
and dlopen() the FreeBSD implementation in case it is needed. As the standard
interfaces in iconv.h define only a iconv_t as a pointer, there is no 
implcit dependency on structure sizes.

As we have the FreeBSD developer in the list of recipients, let me ask 
something:

	Would it be possible to convert the code to be as POSIX compliant as 
	possible? From looking at iconv.c, this would e.g. mean:

	-	Do not include <sys/cdefs.h> as this is something that does
		not exist officially. Solution for FreeBSD:

		Make a hidden include in one of the standard includes

	-	Use POSIX names instead of inofficial names. This 
		would e.g. mean:

		Include <limits.h> instead of <sys/limits.h>

	There may be a need fpr some other similar small changes.

Would this be possible? If yes, we could arrange 100% shared identical code.


> > 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.

Our problem is that we don't know when this will compatibility is reached.

> > 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.

Do you have an idea how to find out which interfaces could be needed without 
starting a longer test period with already integrated replacements?

> > 
> > 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.

It seems that there is no official documentation on the interfaces, or do you 
know one?

Jörg

-- 
 EMail:joerg at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily