> strcasecmp() is obliged to convert all upper-case letters into lower-case
for the comparison
I don't think it is as simple-minded as that (no offense -- you're not
simple-minded either <g>).
I think @John McKown pretty much nailed it. It's an "abstract" compare that
just happens (well, a little more than just happens) to largely conform to
ASCII.
I think the -37 and 122 confirms that it is not a simple "subtract one ASCII
value from another." And yes, I picked 'Z' and '0' specifically because they
order differently ASCII versus EBCDIC. I've deleted my test code now but an
interesting case would be 'A' and 'b', which differ in order between EBCDIC
and ASCII also. A guess would be that the result would be +1, because they
should be one entry apart in the abstract table, unlike their code points,
which are x'20' or x'40' apart. ('A' and 'a' of course compare equal --
that's the whole point, isn't it?)
Yes, the results were astonishing. I assumed a bug in my code.
My code is not only working correctly, it's superfluous! I do initial
development and alpha test on Windows. I have some
hard-coded-in-collating-order tables that I binary search. Most of them use
all-alpha keys and so that order does not matter ASCII (Windows) versus
EBCDIC (MVS). A few tables have mixed alpha, numerics and/or punctuation and
so those I sort into collating sequence on start-up. Well, I needn't have
bothered! As you indicate, lower_bound results are consistent between
Windows and MVS.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On
Behalf Of Thomas David Rivers
Sent: Thursday, June 1, 2017 3:23 PM
To: [email protected]
Subject: Re: strcasecmp() comparing punctuation in ASCII?
Charles Mills wrote:
>It's clearly doing everything in ASCII:
>
>strcasecmp("Z", "0") 122
>
>It's interesting. I use the same compare function for both a sort and
>for a binary search, so it all works correctly -- it's just not working
>the way I think it is.
>
>Charles
>
>
>
I find that very odd...
strcasecmp() is obliged to convert all upper-case letters into lower-case
for the comparison.
Lower-case 'z' in EBCDIC is 0xa9, '0' in EBCDIC is 0xf0. 0xA9 is less than
0xF0; so I would expect strcasecmp() to return a value less than zero.
But - as you point out - in ASCII, 'z' is 0x7a, and '0' is 0x30. 0x7a is
greater than 0x30, so on an ASCII platform I would expect this to return a
positive value (note that 0x7a - 0x30 is 74 - not the 122 that IBM returned,
although both are positive.)
IBM must be mapping the values to some abstract code-points and then
subtracting those...
It _would_ mean that the strcasecmp() results are consistent between ASCII
and EBCDIC environments... which might sometimes be a desirable
characteristic - and other times not...
For IBM-MAIN subscribe / signoff / archive access instructions, send email
to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
