Joseph Langley

Sorry it's taken so long to get you an answer on this. It looks like this bug was fixed in version 2.6.4 by [7f263e3](https://github.com/westes/flex/commit/7f263e35204db8ade3f0fb424f4597d7758caf25). A note in the ChangeLog mentions...

Do you have a test case or a scanner I can use to build a test case for the regression tests? Should be an easy fix and those would really...

Can you check that [this new test](https://github.com/Mightyjo/flex/blob/97e3fb88603d1029699e243143d12be51919e984/tests/yywrap_r.i3.l) captures the behavior you reported? Just want to be sure I'm not fixing another bug altogether :)

Assuming my example matches your problem, this is more difficult to solve than I thought. I [coded up your suggestion](https://github.com/Mightyjo/flex/blob/issue-525/tests/yywrap_r.i3.l) in yy_init_buffer but it causes early termination with the yywrap...

Ok, got the test to stress the execution path that was segfaulting several times without returning to main. The link in my previous comment points to it now. If that's...

It works without calling yywrap in the user code, but when flex does the call it's followed by yyrestart and the rule has to be matched again so you see...

DOH! I'm using %option prefix="test" and pushed code without yywrap renamed. Not really sure why that's working at all.

Okay, updated the test to use the automatic yywrap behavior. You still have to check whether you've gone past your last buffer somehow. I used the do-it-yourself example from the...

Thanks! I read the issue over at macports. A couple of PRs in the pipe will make fixing this a lot easier by separating the output language generation into separate...

See the skeleton_pr branch on [TravisCI](https://travis-ci.com/github/Mightyjo/flex).