Thank you so much
I am sending you the results with both match and no match (added rubbish to same file :)
I will continue to look myself as well.
Ze'ev Atlas
201-801-0378
201-805-0286 (cell)
________________________________
From: "ph10@???" <ph10@???>
To: Ze'ev Atlas <zatlas1@???>
Sent: Tuesday, July 2, 2013 7:13 AM
Subject: Re: [pcre-dev] issue with Posix on z/OS
[Not sent to pcre-dev because of the attachment.]
On Mon, 1 Jul 2013, Ze'ev Atlas wrote:
> I wonder whether pcre_dfa_exec.c, pcreposix.h or pcreposix.c contain
> some reference to ASCII specific character or sequence that might
> cause it to balk on EBCDIC.
Good point. I've had a quick look at the posix code, and there's nothing
obvious therein. Let's concentrate on getting that working before
looking at DFA.
> I did find things like this in pcre_dfa_exec.c, which is obviously
> incorrect in EBCDIC context:
> <snippet>
> #ifdef PCRE_DEBUG
> printf ("%.*sProcessing state %d c=", rlevel*2-2, SP, state_offset);
> if (clen == 0) printf("EOL\n");
> else if (c > 32 && c < 127) printf("'%c'\n", c);
> else printf("0x%02x\n", c);
> #endif
> <snippet>
True, but that code just prints debugging output, and is not normally
included.
> or
> <snippet>
>
> #ifndef EBCDIC
> case 0x2028:
> case 0x2029:
> #endif /* Not EBCDIC */
> <snippet>
>
> which I do not know what to make of, but I do not think any of those
> caused the issue.
Those are Unicode data points which are obviously unavailable in EBCDIC
as their value is greater than 255. That's why they are cut out in
EBCDIC environments.
> The program crashes in a loop using the pchars function and I believe
> it is pcretest.c itself.
> <snippet>
> The -p option cause it (pcretest) to get into an infinite loop of
> printing \x00 and ultimately crash when the program tries to write the
> next \x00 beyond the buffer size (I gave it 30K and it used all of
> them... the printout below just demonstrate the first 305 characters
> of the printout.)
I've just studied the pchars() and pchar() functions in pcretest, and I
cannot see anything that might be causing this.
/the quick brown fox/
the quick brown fox
0:
1:
\x00\x00\x00\x00\x00....
This indicates that the match worked, but that passing back the
information about the match went horribly wrong. I have attached a
modified version of pcretest.c that includes some debugging commands
that will print additional data, which might help.
It might be worth trying a test that fails to match, for comparison.
Feed pcretest -p a couple of lines like this:
/the quick brown fox/
rubbish
and see what happens.
Philip
--
Philip Hazel
