Karl Williamson wrote:
> The following Deparse failure is the most worrisome to me of the
> remaining issues This is because it's returning malformed UTF-8, and it
> looks to me like there is a wild read or write. If the system had a
> tool like valgrind that detects such things, we could quickly figure it
> out. I've looked at the Deparse code, and don't see anything obvious.
> Unless someone has some ideas, this will require single-stepping through
> the code. (Some of the output is garbage, and can't be relied on.)
> # Failed test 2 - \x{} at ../lib/B/Deparse.t line 90
> # got '{
> # my $foo = "Ab\x{100}Ãx{200}¤d\000Ef\x{1000}\cA\x{2000}\cZ";
> # }'
> # expected
> /(?^:^\{\s*\s+my\s+\$foo\s+\=\s+\"Ab\\x\{100\}\\200\\x\{200\}\\237Cd\\000Ef\\x\
> {1000\}\\cA\\x\{2000\}\\cZ\"\;\s*\}$)/
> # Looks like you planned 31 tests but ran 2.
> lib/B/Deparse .................................................
> FAILED--expected 31 tests, saw 2
The malformations in the string seem to come from the \200 and \237
in the input. The only non-\x escapes that survive are \000 and \cA.
Note that the two problematic escapes are outside the ASCII range (on
ASCII platforms). How is EBCDIC supposed to work when you combine
\x{wide} with \234 in the same literal string?
> I'll talk to Dave Mitchell about this one off-list. It may be that the
> test gets skipped.
> t/re/reg_eval_scope ...........................................
> FAILED--expected 48 tests, saw 29
> Out of memory!
I would be interested in seeing the discussion, as I wrote most of
those tests, and recently fixed some (?{}) bugs.
