Re: Patch for iconv-impaired systems

[Owen Taylor <otaylor redhat com>]

Sebastian Wilhelmi <wilhelmi ira uka de> writes:

> Hi,
> 
> recently I tried to compile GLib on aome platform (I forgot which) without
> iconv. I will commit the following patch, if noone objects:
> 
> Now g_convert_* just throws an error, if called on a platfrom without iconv.
> That makes GLib at least compile. It might however be a good idea to at least
> implement some basic and often wanted conversions explicity on such platforms
> later. 
> 
> The guard for including iconv.h is HAVE_ICONV and not HAVE_ICONV_H, because I
> hope, that UNIX has learned its leassons and now standardize the header names
> as well, i.e. "iconv exists iff iconv.h exists and has the prototype".

My opinion is that GLib apps are allowed to depend on the existance
of an iconv() (or perhaps of a g_iconv()), and allowed to assume
g_convert() will not g_error().

Just as a an application should be able to depend on the PNG loader
for gdk-pixbuf being there, they should be able to depend on
being able to get a converter from GB2312 to ISO-8859-2.
(But should check the result of g_convert anyways) 

However, just because a generic application can assume the
presence of a broad set of converters in Glib, does not mean
a specific application needs them. This is especially true
in the "embedded" space, where the set of applications is
fixed, and input text and available fonts can be assumed
to be constrained in encoding. And since conversion tables 
are a big expense for disk and possibly memory space, I think
it would be good to eventually support compiling GLib without
a full iconv, though with the broadly printed caveat :

 "THIS COPY OF GLIB IS NOT SUITABLE FOR GENERAL USE"

So, for right now, the right thing to move the configure
checks for iconv from Pango to GLib; they check in the
C library, then check for Bruno Haible's libiconv.


In the future, a slightly more ambitious plan is that
if the user explicitely compilers GLib with --without-iconv,
to fall back to a simple internal implementation, only
compiled in in that case that just does conversions between

 UTF-8, UTF-16 (BE/LE), UTF-32 (BE/LE?), ISO-8859-1

And does them in the smallest possible amount of code.
(E.g., to convert from UTF-16BE to ISO-8859-1, converts

 UTF16-BE =>  UTF-16 (native, by byteswapping) => UTF-32 (native) => ISO-8859-1

Even that list is rather bigger than I like, but I think
it can be done on top of the supplied conversions in
GLib in ~200 lines of code, with no additional tables.

I do not want to see the inclusion of anything more than that 
in GLib - it would be a bad idea to have to maintain our own 
code conversion tables of any sort; useless duplication
of effort. And the only reason I suggest a fallback tiny
iconv is to save code/data-size for applications where that
is crucial.


But the general principle is that GLib is (partially) a portability
layer, so the facilities available in GLib should not depend on
platform.

Regards,
                                        Owen