Q: problem parsing URI in SIP

[cppden]

Just faced a problem with grammar. I think I'm doing something wrong but don't know how to fix it.
RFC3261 defines SIP-URI as:

SIP-URI          =  "sip:" [ userinfo ] hostport uri-parameters [ headers ]

This was mapped to PEGTL as:

struct userinfo : seq< sor< user, telephone_subscriber >, opt< seq< one<':'>, password > >, one<'@'> > {};
struct SIP_URI : seq< sip_proto, opt< userinfo >, hostport, uri_parameters, opt< headers > > {};

The problem is that it detects userinfo in input which doesn't contain @ like: sip:ss2.biloxi.example.com.

Can you please tell me what am I doing wrong and how to fix it?
Thanks!

[ColinH]

How do you know that it matched userinfo, do you have an action attached to it?

[cppden]

Sure, I have action for user part inside userinfo and the user itself doesn't appear in any other place of this part of grammar.
Perhaps I see what can happen: action is triggered 1st but then the rule is discarded, right?
If it's so, then is there a way to gracefully handle such cases in actions? Otherwise I need to handmade some context to save triggered part and later decide if it was triggered or not...

[ColinH]

Probably what happens is that it is attempted to match userinfo, which successfully matches user to (the first part of) the host name, but because of the missing "@" the full userinfo does not match, and then everything backtracks, but by then the action for user has already been called.

There are several ways to fix this.

The easiest is to use look-ahead with at to make sure that it is in fact a userinfo before parsing again with actions enabled.

Another is to let the rules like user store the data in a temporary location, and only commit it to their final destination once the overarching rule successfully matches.

In addition you can merge common prefixes in the grammar and branch later, so instead of rule = sor< foo, bar > with foo = seq< A, B > and bar = seq< A, C > you rewrite to rule = seq< A, sor< B, C > >.

The look-ahead is the easiest but you parse some parts twice, the merging/rewriting is the most work and can change the grammar to the point of not being very recognisable, however it yields the most efficient results.

[cppden]

Thanks a lot! Now I've used temporary context to capture stored parts and commit them later at once. Code in actions actually become a bit simpler IMHO.
Thanks for sharing your approach for optimization of common prefixes but it's not applicable here at least. Though I will keep it in mind for future.

Could you please elaborate your comment on using at vs temporary location. As I understand in both cases when userinfo is not present the parsing will happen twice - 1st case b/c of look-ahead and in 2nd case b/c of backtracking. But it seems you said that at results in lower performance...

[ColinH]

When using at<> the part that is looked-ahead will be parsed twice even when it matches. Might still be the lesser evil.