apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Trawick" <traw...@gmail.com>
Subject Re: compile failure in server/util_ebcdic.c, due to native iconv needing charset string "ISO8859-1"
Date Sat, 06 Oct 2007 00:02:41 GMT
On 10/3/07, David Jones <oscaremma@gmail.com> wrote:
>
> zOS only recognizes the string "ISO8859-1", other platforms now use
> "ISO-8859-1". zOS is using
> native iconv, not apr-iconv, so can not use apr-iconv/ccs/charset.aliases to
> map the strings.

Also, that particular charset alias support has the luck of knowing
the details of the iconv tables, so there's no question what the alias
has to be mapped to.

> How can apr-util hide the difference when using native iconv()
> (provide a symbol that means ISO-8859-1,

somebody will inevitably want a symbol for some other charset in a
released branch and we can't add new symbols in released branches

> check for alternate charset names
> in the code, or ??)

unclear how complicated this deserves to be; at the very least it
should be straightforward to extend and avoid complicating the
executed path for platforms that already support the normal strings

borrowing from apr-iconv:

/* This is a sorted table of alias -> true name mappings. */
static struct charset_alias {
    const char *name;
    const char *target;
} const charset_alias_list[] = {

#ifdef __MVS__
    {"ISO-8859-1", "ISO8859-1"},
#endif

    {NULL, NULL} };

static const size_t charset_alias_count =
    sizeof(charset_alias_list)/sizeof(charset_alias_list[0]) - 1;

and a couple more functions from the generated charset_alias.h

to keep the generation from aliases file, we'd need different alias
files per platform; maybe default is to use an empty alias file and
for specific platforms use a special alias file

Mime
View raw message