Quantcast

Boost Spirit X3 Symbol table parser segfaults when in a separate compilation unit

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Boost Spirit X3 Symbol table parser segfaults when in a separate compilation unit

Sigbjørn Lund Olsen
Hey, I am trying to learn how to break up Spirit X3 parsers into separate reusable grammars, as encouraged by the example code (rexpr_full and calc in particular) and the presentations from CppCon 2015 and BoostCon. This question is originally asked on StackOverflow (http://stackoverflow.com/questions/43679200/boost-spirit-x3-symbol-table-parser-segfaults-when-in-a-separate-compilation-uni), but I am crossposting it here in the hopes of getting some good answers.

I have a symbol table (essentially mapping different types to a enum class of the types I am supporting), which I would like to reuse in several parsers. The only example of symbol tables I could find is the roman numerals example, which is in a single source file.

When I try to move the symbol table into its own cpp/h file in the style of the more structured examples my parser will segfault if I try to parse any string which is not in the symbol table. If the symbol table is defined in the same compilation unit as the parsers that use it throws an expectation exception instead (which is what I would expect it to do).

I have made a small project which shows what I am trying to achieve and is available here: https://github.com/sigbjornlo/spirit_fruit_mcve

My questions:
- Why does moving the symbol parser to a separate compilation unit cause a segmentation fault in this case?
- What is the "correct" way of making a symbol table reusable in multiple parsers? (In the MCVE I obviously only use the fruit parser in one other parser, but in my full project I want to use it in several other parsers.

Sincerely,
Sigbjørn Lund Olsen

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Boost Spirit X3 Symbol table parser segfaults when in a separate compilation unit

sehe
On 28-04-17 13:36, Sigbjørn Lund Olsen wrote:
> I have made a small project which shows what I am trying to achieve and is
> available here: https://github.com/sigbjornlo/spirit_fruit_mcve
I think the problem has been resolved in the X3 develop branch

> My questions:
> - Why does moving the symbol parser to a separate compilation unit cause a
> segmentation fault in this case?
As the analysis confirmed, the symbol table has nothing to do with it.
The expectation point is triggering the use of a `nullptr` rule-name.
That's fixed in https://github.com/boostorg/spirit/pull/229

You should be able to verify this by e.g. replacing the fruit rule with
something like `lexeme["Apples"] >> attr(FRUIT::APPLES) |
lexeme["Oranges"] >> attr(FRUIT::ORANGES)`.

> - What is the "correct" way of making a symbol table reusable in multiple
> parsers? (In the MCVE I obviously only use the fruit parser in one other
> parser, but in my full project I want to use it in several other parsers.

Your way is correct. In order to alleviate SIOF issues, I strongly
suggest making the fruit grammar factory return by reference:
https://github.com/sigbjornlo/spirit_fruit_mcve/pull/1


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Spirit-general mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spirit-general
Loading...