#458 If '20'x = '09'x then ... incorrectly compares equal!

3.2.0
closed
nobody
5
2012-08-14
2007-11-09
Mark Harsen
No

The following code is broken:

If '20'x = '09'x then Say "BAD!"
Else say "GOOD!"
Exit

Under all previous releases of ooREXX and by any logic, the above program would have said "GOOD!" and rightly so. However, it appears that a '09'x is now being considered "white space" although this is not documented in the reference manual.

This is a very serious problem for people who do a lot of programming using hex data streams and it is a huge backward-compatibility issue!

Changing the code to If '20'x == '09'x then ... fixes the code, but at what cost! We cannot afford to go tons of code making this kind of change and we don't know if other characters are also being considered "white space" too. Please fix this and change it back!!

Thank you, -Mark

Discussion

  • Rick McGuire

    Rick McGuire - 2008-08-15

    Logged In: YES
    user_id=1125291
    Originator: NO

    This feature is in conformance with the ANSI Rexx standard and won't be fixed.

     
  • Mark Harsen

    Mark Harsen - 2008-08-15

    Logged In: YES
    user_id=1289525
    Originator: YES

    Really? It took 9 months, 6 days, 4 hours, and 2 minutes to say, "That’s the way it should work - we're not going to fix it?" Can you please tell me at least why ANSI says it is supposed to work that way? I've run other tests and frankly can't find a single place where this behavior actually helps anything and it is not documented in any REXX help file that it works that way. Can you point me to such a help file so I can understand the "feature"? Will you at least document this strange behavior? Are there any other non-obvious compares that we should watch for?

    How does one get the standard changed? Remember, we used to have to use PARSE UPPER VAR X X instead of the very nice X~upper. We now have time and timespan objects and more. Did the ANSI standard change or has REXX, including IBM's, always been non-compliant? It took me a month or so to find and change all of my hex compares to == so I’ll reluctantly accept this and thanks for the response, but this still appears foolish. I apologize if I appear combative and upset, but I love REXX, promote it anytime I can, and this makes no sense to me.

     
  • Mark Harsen

    Mark Harsen - 2008-08-27

    Logged In: YES
    user_id=1289525
    Originator: YES

    I don’t understand or agree with this, but never mind. At least document this counterintuitive condition.

     
  • J. L. Turriff

    J. L. Turriff - 2008-08-27

    Logged In: YES
    user_id=1850707
    Originator: NO

    When I run this program

    !/usr/bin/rexx

    if '20'x = '09'x then say "'20'x = '09'x => true!"; else say "'20'x = '09'x => false!"
    if '20'x == '09'x then say "'20'x == '09'x => true!"; else say "'20'x == '09'x => false!"
    if '20'x = '0a'x then say "'20'x = '0a'x => true!"; else say "'20'x = '0a'x => false!"
    if '20'x == '0a'x then say "'20'x == '0a'x => true!"; else say "'20'x == '0a'x => false!"
    if '100000'b = '1001'b then say "'100000'b = '1001'b => true!"; else say "'100000'b = '1001'b => false!"
    if '100000'b == '1001'b then say "'100000'b == '1001'b => true!"; else say "'100000'b == '1001'b => false!"
    if '100000'b = '1010'b then say "'100000'b = '1010'b => true!"; else say "'100000'b = '1010'b => false!"
    if '100000'b == '1010'b then say "'100000'b == '1010'b => true!"; else say "'100000'b == '1010'b => false!"

    in ooRexx 3.2.0 (Linux) I see:

    '20'x = '09'x => true!
    '20'x == '09'x => false!
    '20'x = '0a'x => false!
    '20'x == '0a'x => false!
    '100000'b = '1001'b => true!
    '100000'b == '1001'b => false!
    '100000'b = '1010'b => false!
    '100000'b == '1010'b => false!

    which doesn't seem to be consistent even with the ooRexx Reference manual.

    ooRexx Reference, "1.10.3.2. Hexadecimal strings" says,
    "Note: A hexadecimal string is /not/ a representation of a number. It is an escape mechanism that lets a
    user describe a character in terms of its encoding (and, therefore, is machine-dependent). In ASCII, "20"x
    is the encoding for a blank. In every case, a string of the form "..."x is an alternative to a straightfo
    rward string. In ASCII "41"x and "A" are identical, as are "20"x and a blank, and must be treated identica
    lly."

    This makes no mention of the treatment of whitespace characters as interchangeable. In any case, the treat
    ments of tabs and formfeeds are inconsistent with each other.

    ooRexx Reference, "1.11.2.3. Comparison" says that = returns true if the terms are equal (numerically or wh
    en padded), while == returns true if terms are strictly equal (identical).

    It appears that ANSI Rexx is presuming that hex values represent only characters, never binary data, which
    may often be incorrect. While much or most of the time Rexx programs are written to manipulate text string
    s, the language should not assume that this will always be the case, especially when something as low-level
    as hexadecimal or binary data is involved; the values involved might originate from a binary file such as
    JPEG or a load module (executable), in which case the result is definitely incorrect.

    It seems to me that a language should not make any assumptions as to the origin or purpose of the data it is being used to manipulate; that is for the user to decide.

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks