Please review the fixes. If there are no objections I will apply the patch of #1716 (it also includes the patch for bug #1715) together with test units to test for them.
---rony On 06.08.2020 19:47, Rony G. Flatscher wrote: > > The bug report in <https://sourceforge.net/p/oorexx/bugs/1716/> includes a > patch that fixes this. > > ---rony > > > On 05.08.2020 15:16, Rony G. Flatscher wrote: >> >> Having received error reports from users of BSF4ooRexx like >> >> 2 *-* /**/@ >> Error 13 running >> rexx_invoked_via_[fxml_01.fxml]_at_2020_08_05T12_33_24_17Z.rex line 2: >> Invalid character in program. >> Error 13.1: Incorrect character in program "@" ('40'X). >> >> and looking up the execution paths in those cases, it turns out that the >> ooRexx .routine class >> gets used to create the executable in those cases with a string array >> representing the compiled >> and encoded Rexx program. >> >> So the "new" method of the .routine class gets the compiled and encoded >> source supplied as an >> array of strings, e.g.: >> >> #!/usr/bin/env rexx >> /**/@REXX@ >> LyoqL0BSRVhYAAAAAAAAAGcrKgAgAAAAVOwAAAAAAABwEgAAVPq7VhgAAAACAAAAAAAAAAAA >> AAAAAAAAgB68ViAAAAACAAAAKAAAAAAAAABwAAAAOAAAAAAAAADkSrxWOAAAAAIAAAAFAACA >> ... cut ... >> >> Supplying the compiled and encoded data as a single string to the .routine >> class does not work as >> this issues the error "13.1, Invalid character in program" caused by the >> presence of a LF ('0A'x) >> character, here a rexxtry example: >> >> infile=.stream~new("nutshell_01.rex-compiled")~~open("read") >> ........................................... rexxtry.rex on WindowsNT >> pgm=infile~charin(infile~chars) >> ........................................... rexxtry.rex on WindowsNT >> infile~close >> ........................................... rexxtry.rex on WindowsNT >> r1=.routine~new("aha",pgm) >> Oooops ! ... try again. Invalid character in program. >> Incorrect character in program " >> " ('0A'X). >> rc = 13.1 ................................. rexxtry.rex on WindowsNT >> >> As a compiled and encoded form of a Rexx program always has the string >> "/**/@REXX@" as the value >> for its second line it would be possible to determine that the String array >> comes from a compiled >> and encoded Rexx program. Rather than creating an error in this case, the >> routine object could >> get created successfully from the String array representing a compiled and >> encoded Rexx program. >> >> Are there any objections to try to enhance the "new" method of the .routine >> (and the .method) >> class such that the string array can represent a compiled and encoded Rexx >> program? >> >> ---rony >>
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
