Simple parsing problem

Eric Fowler <>
Sun, 21 Jun 2009 20:09:55 -0700

          From comp.compilers

Related articles
Simple parsing problem (Eric Fowler) (2009-06-21)
Re: Simple parsing problem (Hans Aberg) (2009-06-23)
Re: Simple parsing problem (Waldek Hebisch) (2009-06-23)
| List of all articles for this month |

From: Eric Fowler <>
Newsgroups: comp.compilers
Date: Sun, 21 Jun 2009 20:09:55 -0700
Organization: Compilers Central
Keywords: parse, question
Posted-Date: 22 Jun 2009 18:11:32 EDT

This should be easy practice for the experts ..
I am writing a bison grammar to parse strings coming from various
kinds of attached devices.

One of the strings is of the form:
$FOO,field1,field2, 0,a,1,b,3,c, ....<CRLF>

where there are a variable number of paired fields of the form
<number> COMMA <text> COMMA. The comma is always a delimiter here,
the text contains no commas.

This one was easy, I did it like this:
FOO opt_token opt_token dse_data_set
{mumble ...}

dse_data_pair dse_data_set
| dse_data_pair

opt_token opt_token
{ code here ...

        memcpy($$, $2, sizeof($$)/sizeof(*$$) - 1);
{ *$$ = 0;}

All well and good. Now I got this curveball - it is the same as the
other one, but it has another opt_token field after the variable
length list of pairs:


[An opt_token is just a comma delimited field that might be empty, BTW. ]

I am getting shift-reduce conflicts when I try to handle this like this:
FOOBAR opt_token opt_token dse_data_set opt_token

I can vaguely see why this is happening ... the parser can't tell the
diff between opt_tokens that are in pairs or 'in the wild'. But I am
not clear how to fix this.

I could, I suppose, define something equivalent to opt_token that does
the same thing, but is different, and use it in my dse_data_pair, or
alternatively use it for my last opt_token. But I am wondering if
there is a cleaner play.

Thanks very much


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.