Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Many parser should not handle infinite loop #198

Closed
wants to merge 2 commits into from
Closed

Many parser should not handle infinite loop #198

wants to merge 2 commits into from

Conversation

minamorl
Copy link
Contributor

Related to #197

This changes contains runtime detection of infinite loop. If current parsing position is exact same as each parser's result, it should be infinite loop.

@coveralls
Copy link

coveralls commented Aug 20, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling e7935c1 on minamorl:fix-many into ff13033 on jneen:master.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling e7935c1 on minamorl:fix-many into ff13033 on jneen:master.

@wavebeem
Copy link
Collaborator

I really like this! It could be backwards incompatible though, if someone uses a parser with side effects in it. I think maybe it makes more sense to wait for Parsimmon 2.0 to accept this PR?

Hmm.

@minamorl
Copy link
Contributor Author

minamorl commented Aug 21, 2017

As you pointed out, there's a possibility to break backward compatibility. All context-dependent parsers, which decides to consume input by context or not, will be affected by this change. It means the parser switches context inside infinite loop. Such kind of parser is too dependent to current many() implementation.

FYI I researched other parsing library Nom(Rust) and Parsec(Haskell). Both of these reject empty string. Here's a reference:

My opinion is it is okay to ship this under current 1.x version.

@wavebeem
Copy link
Collaborator

Hmm, I think you're right. I should clarify in https://github.com/jneen/parsimmon/blob/master/API.md#side-effects that side effects also include randomness or reading from global state during parsing. It's already an expectation that bad things can happen if you do that.

@@ -18,4 +18,9 @@ suite('many', function() {
assert.equal(parser.parse('xxxxxy').value, 'y');
});

test('can process infinite loop', function() {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

test('aborts on 0-character parse', ...) maybe?

src/parsimmon.js Outdated
return Parsimmon(function(input, i) {
var accum = [];
var result = undefined;

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please remove the spaces on this line

for (;;) {
result = mergeReplies(self._(input, i), result);
if (result.status) {
if (i === result.index) {
return makeFailure(i, 'Infinite loop has been detected in many() parser');
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, should this use makeFailure, or throw new Error(...). it isn't a failed parse? it's a broken parser? i don't know.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems you are right. I will change to Error so that it is more suitable in this context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is off topic but i wish if parsimmon had custom errors containing its own kind...

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that might be good!

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@minamorl Do you still have time to change to throw new Error(...)?

@coveralls
Copy link

Coverage Status

Coverage remained the same at 100.0% when pulling 658fc89 on minamorl:fix-many into 8245d53 on jneen:master.

@coveralls
Copy link

coveralls commented Aug 22, 2017

Coverage Status

Coverage remained the same at 100.0% when pulling 658fc89 on minamorl:fix-many into 8245d53 on jneen:master.

@wavebeem
Copy link
Collaborator

@minamorl do you still want to work on this PR? or should I finish it

@wavebeem
Copy link
Collaborator

Closing in favor of #221 due to merge conflicts. Thank you @minamorl for your work on this issue!

@wavebeem wavebeem closed this Dec 27, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants