You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by David Jones <os...@gmail.com> on 2007/10/03 14:54:16 UTC
compile failure in server/util_ebcdic.c, due to native iconv needing charset string "ISO8859-1"
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.
How can apr-util hide the difference when using native iconv()
(provide a symbol that means ISO-8859-1, check for alternate charset names
in the code, or ??)
This is the patch i'm running with, works but any suggestions for
improvement?
Index: xlate/xlate.c
===================================================================
--- xlate/xlate.c (revision 579232)
+++ xlate/xlate.c (working copy)
@@ -74,6 +74,11 @@
else if (page == APR_LOCALE_CHARSET) {
return apr_os_locale_encoding(pool);
}
+#ifdef __MVS__
+ else if (!strcasecmp(page, "ISO-8859-1")) {
+ return "ISO8859-1";
+ }
+#endif
else {
return page;
}
============================
For reference the patch that zOS can't handle:
Revision 104078 server/util_ebcdic.c changed from using "ISO8859-1" to
"ISO-8859-1":
Revision 104078 - (view) (download) (annotate) - [select for diffs]
Modified Tue Jun 29 13:33:24 2004 UTC (2 years, 6 months ago) by martin
File length: 3069 byte(s)
Diff to previous 102619 (colored)
Use standardized names for ISO-8859-1, see
http://www.iana.org/assignments/character-sets
(Using the name iso8859-1 may still work, because it is aliased in
apr-iconv/ccs/charset.aliases)
Re: compile failure in server/util_ebcdic.c, due to native iconv needing charset string "ISO8859-1"
Posted by Jeff Trawick <tr...@gmail.com>.
On 10/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> Jeff Trawick wrote:
> > On 10/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> >> I really wonder, if z/OS is so crippled, if we shouldn't simply
> >> recommend using apr-iconv?
> >
> > that's a lot of punishment for not supporting "ISO-8859-1" ;) users
> > of apr apps can't use the same transformations that they use with
> > other apps (ftp, telnet, and everything else)
>
> Recommend isn't punishment (demand might be ;-)
Thanks so much ;)
> But my question is, if this is unrecognized, the default iconv is likely
> to have other deficiencies.
Factors such as age, use in well-known applications, very strong
requirement for working iconv on the platform, very high expectations
for defect fixes among customers, etc. would support the theory that
any real operational problems would have been resolved long ago.
All I can say for sure based on the history of this code is that
- "ISO8859-1" works on z/OS but not Fujitsu mainframes, hence Martin's
change to "ISO-8859-1"
- "ISO-8859-1" works on Fujitsu but not z/OS, hence the current discussion
(I suspect that most platforms support either string.)
--/--
At any rate, I'm eager for an unpatched apr, without apr-iconv,
working reasonably on z/OS, and am thinking that something more
extensible than David's patch is needed.
Re: compile failure in server/util_ebcdic.c, due to native iconv
needing charset string "ISO8859-1"
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Jeff Trawick wrote:
> On 10/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
>> I really wonder, if z/OS is so crippled, if we shouldn't simply
>> recommend using apr-iconv?
>
> that's a lot of punishment for not supporting "ISO-8859-1" ;) users
> of apr apps can't use the same transformations that they use with
> other apps (ftp, telnet, and everything else)
Recommend isn't punishment (demand might be ;-)
But my question is, if this is unrecognized, the default iconv is likely
to have other deficiencies.
I will be rolling apr 1.2.1 shortly based on win32 build fixes, and would
encourage any patches which make it easier to (optionally) build this on
unix and derivatives.
Re: compile failure in server/util_ebcdic.c, due to native iconv needing charset string "ISO8859-1"
Posted by Jeff Trawick <tr...@gmail.com>.
On 10/5/07, William A. Rowe, Jr. <wr...@rowe-clan.net> wrote:
> I really wonder, if z/OS is so crippled, if we shouldn't simply
> recommend using apr-iconv?
that's a lot of punishment for not supporting "ISO-8859-1" ;) users
of apr apps can't use the same transformations that they use with
other apps (ftp, telnet, and everything else)
Re: compile failure in server/util_ebcdic.c, due to native iconv
needing charset string "ISO8859-1"
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I really wonder, if z/OS is so crippled, if we shouldn't simply
recommend using apr-iconv?
Bill
Jeff Trawick wrote:
> On 10/3/07, David Jones <os...@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
>
>
Re: compile failure in server/util_ebcdic.c, due to native iconv needing charset string "ISO8859-1"
Posted by Jeff Trawick <tr...@gmail.com>.
On 10/3/07, David Jones <os...@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