https://svn.boost.org/trac10/ticket/8447 <p> The behavior of the result parser unexpectedly depends from order of the 'repeat' statements within 'Alternative' parser. </p> <p> As example: "repeat(n)[...] | repeat(m)[...]" works not like "repeat(m)[...] | repeat(n)[...]" in some circumstances. </p> <p> I've been using the example from this <a class="ext-link" href="http://stackoverflow.com/questions/4009752/boost-spirit-bug-when-mixing-alternates-with-optionals"><span class="icon">​</span>http://stackoverflow.com/questions/4009752/boost-spirit-bug-when-mixing-alternates-with-optionals</a> <a class="missing wiki">StackOverflow</a> thread to identify problem (sample source is attached below). </p> <p> The output of the result application: </p> <p> in boost 1.44 (bug was fixed after stackoverflow thread): </p> <blockquote> <p> Success: '123FAA22' Failed to match. Success: '123F' Success: '1A22' </p> </blockquote> <p> in boost 1.45 (seems to be correct): </p> <blockquote> <p> Success: '123FAA22' Success: '12AA' Success: '123F' Success: '1A22' </p> </blockquote> <p> in boost 1.49 : </p> <blockquote> <p> Success: '123FAA22' Success: '12AA12AA' (Incorrect) Success: '123F' Success: '1A22' </p> </blockquote> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/8447 Trac 1.4.3 Nikita Kniazev <nok.raven@…> Thu, 07 Dec 2017 15:11:11 GMT https://svn.boost.org/trac10/ticket/8447#comment:2 https://svn.boost.org/trac10/ticket/8447#comment:2 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> Ticket