- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - OpenVMS
- >
- CRTL bug?: iconv_open doesn't do ASCII
Operating System - OpenVMS
1748180
Members
4127
Online
108759
Solutions
Forums
Categories
Company
Local Language
юдл
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
юдл
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-06-2003 03:03 PM
тАО05-06-2003 03:03 PM
CRTL bug?: iconv_open doesn't do ASCII
On an OpenVMS Alpha 7.3-1 system with no special language kits installed, it appears (based on the stock files supplied at the location pointed to by SYS$I18N_ICONV) that the following character set names are supported for translation by iconv_open:
ISO8859-1
UCS-2
UCS-4
VTF-7
A bit of experimentation shows that other character set names are considered invalid by iconv_open. So far so good -- that's what I would expect. However, translating character sets is not something done in the abstract; what I really want is to translate between my local character set and some other one.
The standard supported method for obtaining the canonical name of my local character set is to call "nl_langinfo(CODESET);", which returns "ASCII" on my system. But "ASCII" is not in the list of character sets supported for translation by iconv_open, and indeed iconv_open considers it invalid.
I am aware of the documentation for creating additional character set translations using the iconv utility. It seems to me, though, that internal consistency between what nl_langinfo returns and what iconv_open can use should be available out of the box. The lack of it will break a lot of open source software and is already necessitating some VMS-specific hacks in a project I'm involved with. It also seems that fixing this would probably just be a data change and not require touching the CRTL code.
ISO8859-1
UCS-2
UCS-4
VTF-7
A bit of experimentation shows that other character set names are considered invalid by iconv_open. So far so good -- that's what I would expect. However, translating character sets is not something done in the abstract; what I really want is to translate between my local character set and some other one.
The standard supported method for obtaining the canonical name of my local character set is to call "nl_langinfo(CODESET);", which returns "ASCII" on my system. But "ASCII" is not in the list of character sets supported for translation by iconv_open, and indeed iconv_open considers it invalid.
I am aware of the documentation for creating additional character set translations using the iconv utility. It seems to me, though, that internal consistency between what nl_langinfo returns and what iconv_open can use should be available out of the box. The lack of it will break a lot of open source software and is already necessitating some VMS-specific hacks in a project I'm involved with. It also seems that fixing this would probably just be a data change and not require touching the CRTL code.
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-07-2003 09:45 AM
тАО05-07-2003 09:45 AM
Re: CRTL bug?: iconv_open doesn't do ASCII
Hi Craig,
not sure it helps, but there is an CRTL ECO 1 available for 7.3-1. This did touch iconv. While it does not explicitly mention your problem you never now what engineering did under the covers ;-)
Greetings, Martin
not sure it helps, but there is an CRTL ECO 1 available for 7.3-1. This did touch iconv. While it does not explicitly mention your problem you never now what engineering did under the covers ;-)
Greetings, Martin
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-13-2003 10:26 AM
тАО05-13-2003 10:26 AM
Re: CRTL bug?: iconv_open doesn't do ASCII
Thanks, Martin. I'll double check but I think I already have that ECO installed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО05-17-2003 06:27 AM
тАО05-17-2003 06:27 AM
Re: CRTL bug?: iconv_open doesn't do ASCII
Seems like a bug to me. I bet that the character set is really 8859-1 or maybe DECstd 169 even if it's reported as ASCII by nl_langinfo...
So you can probably see what is reported ASCII on VMS as 8859-1 or DECstd 169. But you should however make sure to log this as a problem with HP so that they get the chance to do something about this, because it really seems to be a bug.
/ShyGuy
Isn't every computer a Digital computer?
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP