| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 647.1 | | AUSS::GARSON | DECcharity Program Office | Mon May 26 1997 22:04 | 5 |
| re .0
Looks buggy. IPMT and HOPE.
I tested VAX VMS V6.2 and Alpha VMS V6.2 and they both behave this way.
|
| 647.2 | | TAV02::GALIA | Galia Reznik, Israel Software Support | Tue May 27 1997 02:38 | 5 |
| Hi,
It goes all the way up to V7.1 .
Galia.
|
| 647.3 | not ASCII | COMEUP::SIMMONDS | loose canon | Tue May 27 1997 03:26 | 8 |
| Re: .0
But codes with values > 127 are not in the ASCII character set!
If a workaround is acceptable, try f$cvui(0,8,ch0) .LT. f$cvui(0,8,ch1)
for example..
Fwiw,
John.
|
| 647.4 | | TLE::REAGAN | All of this chaos makes perfect sense | Tue May 27 1997 10:39 | 4 |
| Exactly what "ASCII" are you talking about? I've assumed that DCL
strings conform to ISO Latin-1.
-John
|
| 647.5 | IPMT | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue May 27 1997 11:37 | 10 |
|
Use the NCS or multinational comparison routines and a program image,
if possible.
DCL and other low-level and/or older OpenVMS components are not designed
for eight-bit (or Unicode) operations. We are in the process of adding
some Unicode support for an upcoming OpenVMS release, but I do not know
if this includes enhancements to DCL.
You can try that IPMT...
|
| 647.6 | | QUARK::LIONEL | Free advice is worth every cent | Tue May 27 1997 12:05 | 7 |
| This makes no sense to me. VMS has been supporting the "DEC Multinational
Character Set" for just about its entire life. The character compare
instruction on VAX (and I would hope the equivalent Alpha code) properly
handles comparisons of 8-bit characters using an unsigned comparison. This
sounds like an outright bug to me.
Steve
|
| 647.7 | | AUSS::GARSON | DECcharity Program Office | Tue May 27 1997 20:11 | 13 |
| additional to .6
Furthermore the VMS doco explicitly states that DCL strings can contain
MCS characters. What it doesn't state is what collating sequence is
used in comparisons. In the absence of any statement one would expect
direct ordinal value comparison (i.e. no funny language specific rules)
and with the accompanying text talking about values 0..127 and values
128..255 one might reasonably expect the non-ASCII part of the MCS to
compare above the ASCII part.
It is true that DCL (VMS in general) OOTB has never supported other
character sets fully but vanilla comparison should have the expected
behaviour.
|
| 647.8 | | COMEUP::SIMMONDS | loose canon | Wed May 28 1997 04:53 | 15 |
| Re: .6
The DCL module involved does indeed use CMPC5, but this instruction has
never performed strictly unsigned comparison.. both C _and_ N condition
code are changed so that you can choose the following conditional branch
appropriately..
The 'bug' seems to be that there is a common path after integer and
string compares which only does a signed test.. (a previous instance of
this reply blamed D. N. CUTLER, but there's evidence that his original
intentions have been altered somewhat..)
(Alpha V7.1: module EXPRESS.MAR, listing line 1501)
John.
|
| 647.9 | | TAV02::GALIA | Galia Reznik, Israel Software Support | Thu May 29 1997 04:48 | 11 |
| Hi,
It seems to me, that a common sense expectation for an unsigned
comparison in this case is much stronger than the definition of what
is ASCII and what not in DEC Multonational Character Set.
From .8 it is clear, that I should QAR it.
Thanks to you all for your comments.
Galia Reznik,
MCS, Israel.
|