|
|
|
|
|
|
| Author |
Message |
John E. Malmberg *nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
Posted: Tue Jun 06, 2006 3:39 am Post subject:
[patch@28349] vmsify - full EFS charset support
|
|
|
There are three encodings available for ODS-5 disks;
ISO-8859-x - Default.
UTF-8 (OpenVMS can not tell the difference between UTF-8 and
ISO-8859)
VTF-7 - UCS-2 encoded in HEX and prefixed with ^U.
The OpenVMS C Runtime can handle UTF-8 and ISO-8859 character sets in
both UNIX and OpenVMS formats. In VMS format some characters show up as
^xx where the xx are the HEX-ASCII representations of a character that
does not show up in the ISO-8859-1 set.
The OpenVMS C runtime can only handle VTF-7 encoded UNICODE in OpenVMS
format at this time. So for full VTF-7 support before then, any C
library routine that deals with a filename will need to be wrapped with
the internal version of a vmsify() call, and the C runtime calls will
need to return the filenames in VMS format and converted to UNIX format.
This patch overhauls vmsify() for the optional support of EFS character
set, including either encoding UTF-8 characters as is, or optionally
encoding in VTF-7 format for compatibility with Advanced Server.
This sets up new routines for receiving or setting the UTF-8 flag from
the perl internal structures to the routines related to vmsify and unixify.
Todo next:
Update UNIXIFY to fully handle EFS characters and optionally VTF-7 encoding.
Update UNIXPATH/VMSPATH routines to optimize them. Currently VMSPATH
calls VMSIFY(), and VMSIFY now does almost all the work to do a VMSPATH.
Patches for [.vms.ext]filespec.t for testing the new routines are
waiting for the above to be completed.
Patches for [.vms.ext]filespec.pm to better document how vmsify and
unixify work are also waiting for the above to be completed.
I need to come up with some test routines to verify that UTF-8 and VTF-7
get encoded/decoded properly from OpenVMS to UNIX.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
 |
John E. Malmberg *nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
Posted: Wed Jun 07, 2006 3:56 am Post subject:
Re: [patch@28349] vmsify - full EFS charset support
|
|
|
Patch does not work on a threaded build, needs a small rework.
I will resubmit tomorrow if the overnight threaded build works.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
 |
Craig A. Berry *nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
Posted: Wed Jun 07, 2006 4:11 am Post subject:
Re: [patch@28349] vmsify - full EFS charset support
|
|
|
At 11:39 PM -0400 6/5/06, John E. Malmberg wrote:
| Quote: | There are three encodings available for ODS-5 disks;
|
I think you mean for filenames on ODS-5 disks. I guess that's implicit in EFS.
| Quote: | --- /rsync_root/perl/vms/vms.c Tue May 30 23:23:07 2006
+++ vms/vms.c Sun Jun 4 22:12:56 2006
|
Wow. I"m working on this. It didn't compile as is in a threaded
configuration or a default configuration either. It adds 794 lines
of code to vms.c and I don't think I will ever find time to read it
all, much less understand it, so do please submit tests. I will get
it in as soon as I get it to compile and I'm satisfied it doesn't
introduce failures for tests we already have.
| Quote: | +/* This routine converts a UCS-2 character to be VTF-7 encoded.
+ */
+
+static void ucs2_to_vtf7
+ (char *outspec,
+ unsigned long ucs2_char,
+ int * output_cnt)
+{
|
Why not use the CRTL's iconv() ? I think ucs2-to-vtf7 is one of the
translations supported even if you have not installed the optional
internationalization kit, but I could be wrong.
| Quote: |
@@ -9846,8 +10558,7 @@
dev_desc.dsc$b_dtype = DSC$K_DTYPE_T;
dev_desc.dsc$b_class = DSC$K_CLASS_S;
dev_desc.dsc$a_pointer = (char *) dev; /* Read only parameter */
- status = lib$getdvi(&item, 0, &dev_desc, &lockid, 0, 0);
- if (!(status & 1)) {
+ if (!$VMS_STATUS_SUCCESS(status)) {
switch (status) {
case SS$_NOSUCHDEV:
SETERRNO(ENODEV, status);
|
I think you threw the baby out with the bathwater on that one.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
 |
Craig A. Berry *nix forums Guru Wannabe
Joined: 27 May 2005
Posts: 143
|
Posted: Wed Jun 07, 2006 12:25 pm Post subject:
Re: [patch@28349] vmsify - full EFS charset support
|
|
|
At 11:11 PM -0500 6/6/06, Craig A. Berry wrote:
| Quote: | --- /rsync_root/perl/vms/vms.c Tue May 30 23:23:07 2006
+++ vms/vms.c Sun Jun 4 22:12:56 2006
Wow. I"m working on this. It didn't compile as is in a threaded
configuration or a default configuration either. It adds 794 lines
of code to vms.c and I don't think I will ever find time to read it
all, much less understand it, so do please submit tests. I will get
it in as soon as I get it to compile and I'm satisfied it doesn't
introduce failures for tests we already have.
|
Sorry for the grumpy tone. I was just a little taken aback that
such massive changes were necessary, but since they are, I'm glad
you've made them . I've applied this with very slight
modifications as #28367. I modified vms_split_path() so that it does
not try to pass around thread context; as far as I can tell, it does
not manipulate any global data, so there's not much reason for it to
do that, and now it can also be used in other places that do not have
thread context handy. The only other change was that I restored a
lib$getdvi call in encode_dev() that your patch deleted -- just looks
like PF4 got whacked one time too many.
If there is any more documentation available about VTF-7, I'd
appreciate pointers.
--
________________________________________
Craig A. Berry
mailto:craigberry@mac.com
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser |
|
| Back to top |
|
 |
John E. Malmberg *nix forums Guru Wannabe
Joined: 30 May 2005
Posts: 264
|
Posted: Wed Jun 07, 2006 12:46 pm Post subject:
Re: [patch@28349] vmsify - full EFS charset support
|
|
|
Craig A. Berry wrote:
| Quote: | At 11:11 PM -0500 6/6/06, Craig A. Berry wrote:
Sorry for the grumpy tone. I was just a little taken aback that
such massive changes were necessary, but since they are, I'm glad
you've made them . I've applied this with very slight
modifications as #28367. I modified vms_split_path() so that it does
not try to pass around thread context; as far as I can tell, it does
not manipulate any global data, so there's not much reason for it to
do that, and now it can also be used in other places that do not have
thread context handy. The only other change was that I restored a
lib$getdvi call in encode_dev() that your patch deleted -- just looks
like PF4 got whacked one time too many.
|
I just started a threaded build with the lib$getdvi() call restored. I
added the thread context to the callers of vms_split_path().
I thought that the _ckvmssts() macro required the thread context. At
least that seems to be what it is showing on my listings because it
calls Perl_croak() which needs the thread context.
I must have slipped with the editor when applying your patch to my changes.
| Quote: | If there is any more documentation available about VTF-7, I'd
appreciate pointers.
|
The documentation is scattered about VTF-7. The fastest way I have
found to get to the references is to enter it as a keyword to a google
search, as it is a uniquely OpenVMS name.
I did the conversion manually mainly to avoid the overhead of setting up
and calling the iconv() routines each time. I was not sure if I could
open an iconv context in the main thread and then use it in all the
resulting threads.
-John
wb8tyw@qsl.net
Personal Opinion Only |
|
| Back to top |
|
 |
Google
|
|
| Back to top |
|
 |
|
|
The time now is Tue Dec 02, 2008 2:55 pm | All times are GMT
|
|
Loans | Get Rid of Debt | Credit Cards | Credit Card Consolidation | Online Advertising
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|