[antlr-interest] Dealing with issues in non-greedy (.)* rules
Marc-André Laverdière
ma_laver at ciise.concordia.ca
Mon May 14 07:47:40 PDT 2007
Hello,
It looks like the issue is deeper than what I thought. Let me show an
example:
20 BeginBehavior
21 const int cert_type_priority[3] = { GNUTLS_CRT_X509,
GNUTLS_CRT_OPENPGP, 0};
22 gnutls_init (session, GNUTLS_CLIENT);
23 gnutls_set_default_priority (session);
24 gnutls_certificate_type_set_priority (session, cert_type_priority);
25 gnutls_certificate_allocate_credentials(xcred);
26 gnutls_credentials_set (session, GNUTLS_CRD_CERTIFICATE, xcred);
27 int socketflags = fcntl(socket,F_GETFL);
28 if ((socketflags & O_NONBLOCK) != 0) fcntl(socket,F_SETFL,
socketflags ^ O_NONBLOCK);
29 EndBehavior
The parsing gives me:
line 21:30 no viable alternative at character '['
line 21:32 no viable alternative at character ']'
line 21:77 no viable alternative at character ';'
line 22:38 no viable alternative at character ';'
line 23:39 no viable alternative at character ';'
line 24:68 no viable alternative at character ';'
line 25:48 no viable alternative at character ';'
line 26:65 no viable alternative at character ';'
line 27:41 no viable alternative at character ';'
line 28:20 mismatched character ' ' expecting '&'
line 28:73 no viable alternative at character '^'
line 28:86 no viable alternative at character ';'
Which means that certain characters are not accepted. Acutally, when I
print the resulting token, these are missing!
I don't even have a lexer rule that mentions ';'!
What am I doing wrong? I'm working with k=2. Should I crank it up for
that rule?
Terence Parr wrote:
>
> On May 10, 2007, at 12:08 PM, Marc-André Laverdière wrote:
>
>> Hello,
>>
>> I just wanted to a) share a hack and b) ask for some help dealing with
>> blob-matching rules.
>>
>> I have the following rule:
>> sh_code_blob
>> : ( options {greedy=false;} : . )*
>> {if (false) throw new RecognitionException();};
>>
>> a) you will notice the "if (false) throw new RecognitionException();"
>> This hack takes care of the compilation exception in the generated
>> parser for this rule, since the generated code tries to catch an
>> exception that won't ever be thrown.
>
> Hmm... i think .+ would be better. .* matches nothing, not a
> particularly useful input. ;)
>
> that should remove error.
>
> Ter
>
--
Marc-André LAVERDIÈRE, B. Eng., M. A. Sc. (in progress)
Computer Security Laboratory - Laboratoire de sécurité informatique
CIISE, Université Concordia University, Montréal, Québec, Canada
www.ciise.concordia.ca
/"\
\ / ASCII Ribbon Campaign
X against HTML e-mail
/ \
"Perseverance must finish its work so that you may be mature and
complete, not lacking anything." -James 1:4
More information about the antlr-interest
mailing list