Le Mardi, 23 Février 2012 17:15:27 +0000 (GMT),
Philip Hazel <ph10@???> a écrit :
> pcredemo -g
pcredemo segfaults when using the -g param, as in the following (cmd
on a single line) :
./pcredemo -g "rate (?'rate'\d+)Kbit|ceil (?'ceil'\d+)Kbit"
"quantum 12500 rate 300000Kbit ceil 540000Kbit "
Match succeeded at offset 14
0: rate 300000Kbit
1: 300000
Named substrings
(2) ceil:
(1) rate: 300000
Match succeeded again at offset 30
0: ceil 540000Kbit
1:
2: 540000
Named substrings
Segmentation fault (core dumped)
I'm new to pcre (since yesterday) and I think this is solved, from
what I can see so far, by adding a call to pcre_fullinfo() in order to
somehow give some meaning to name_table before tabptr shifts that
value:
/* Loop for second and subsequent matches */
for (;;)
{
[ snip ]
// Added bit:
(void)pcre_fullinfo(
re,
NULL,
PCRE_INFO_NAMETABLE,
&name_table);
// Back to original code:
if (namecount <= 0) printf("No named substrings\n"); else
{
unsigned char *tabptr = name_table;
printf("Named substrings\n");
for (i = 0; i < namecount; i++)
{
int n = (tabptr[0] << 8) | tabptr[1];
[ etc...]
The pcre_fullinfo() call with PCRE_INFO_NAMEENTRYSIZE could also be
added there although adding it did not seem to change anything, tabptr
being incremented seemingly OK in any case.
If there is no other catch in proceeding like this, it seems quite
straightforward. Not bad at all. Can I ask what would be the pcre
syntax to use to cope with a paragraph (Linux newlines) instead of a
single line using this -g functionality ?
Thanks.
