User talk:Geoffhacker
fixing a REXX bug
Please check (execute) the program after you "fix" a bug to ensure that the output is (still) correct. There was no bug in the REXX program you "fixed". The output was correct with the original program. -- Gerard Schildberger (talk) 23:20, 3 March 2015 (UTC)
- My bad. But when I tried to run your program as-is, I received the following message:
- c:\Users\hackerg\Downloads>rexx lcsubstr.rex
- 10 *-* parse arg x,y,$
- Error 13 running c:\Users\hackerg\Downloads\LCSubstr.rex line 10: Invalid chara
- cter in program
- Error 13.1: Incorrect character in program "$" ('24'X)
- As it is, I assume that that must mean that there is no boundary checking in REXX. When I tried to implement it as-is in C# I got an out-of-bounds error, and by subtracting j from the length of x I corrected that error and produced the correct result when I executed the program. --Geoffhacker (talk) 07:30, 4 March 2015 (UTC)
Which Classic REXX are you using?
I suspect that you may be using a non-Classic REXX, such as ooRexx or possibly oRexx. ooRexx has it's own Rosetta Code section, ooRexx.
The ooRexx and oRexx languages have restrictions over what Classic REXX specifies as to what characters can be used for variables.
A $ (dollar sign) is a legal character that can be used for variables (for all Classic REXXes).
REXX does no boundary checking (in this substr use) in that in REXX, you are allowed to ask for 10 characters starting from position three in a five character string (or for that matter, even a null string).
For instance: <lang rexx>x=12345 y=substr(x,3,10)</lang>
REXX will set Y to 345 appended with seven blanks (for a total length of ten). [You can change this behavior (the pad character) by specifying a fourth argument to the substr BIF.]
This is not an error, it is how the substr BIF (and other BIFs) are defined to behave. The left and right BIFs also behave this way.
You can even ask for the twenty-first character from the same string: <lang rexx>x=12345 y=substr(x,21,1)</lang> which will return a single blank.
When I executed your "fix" (in REXX), that version produced the wrong result. It doesn't matter if a C version produces the correct result or not, other language's substr BIF don't necessarily behave the same way as REXX's substr BIF. I think (as I recall) that PL/I's substr BIF also behaves differently than REXX's BIF.
As the REXX program is (now) correctly written, it produces the correct result.
In general, one shouldn't try REXX transliterated programs in other languages without knowing how REXX BIFs behave.
Another piece of advice is to actually execute the changed/"fixed" REXX program to verify that it produces the correct result(s). -- Gerard Schildberger (talk) 08:22, 4 March 2015 (UTC)