[
https://issues.apache.org/jira/browse/DAFFODIL-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16581030#comment-16581030
]
Steve Lawrence edited comment on DAFFODIL-1960 at 8/15/18 12:43 PM:
--------------------------------------------------------------------
This is a similar issue to DAFFODIL-1985, but the code referenced in this bug
no longer exists. The other bug better describes the issue as it related to the
existing code base, so closing this as a duplicate.
was (Author: slawrence):
This is a similar issue to DAFFODIL-1964, but the code referenced in this bug
no longer exists. The other bug better describes the issue as it related to the
existing code base, so closing this as a duplicate.
> RepUnboundedParser incorrectly handling points of uncertainty
> -------------------------------------------------------------
>
> Key: DAFFODIL-1960
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1960
> Project: Daffodil
> Issue Type: Improvement
> Components: Back End
> Affects Versions: 2.1.0
> Reporter: Steve Lawrence
> Assignee: Steve Lawrence
> Priority: Major
> Fix For: 2.2.0
>
>
> The RepUnboundedParser currently creates two marks: startState and
> priorState. The priorState mark changes as we go through each repetition of
> the array. The startState mark never changes. If an error occurs during a
> repetition and a discriminator *IS NOT* set, we reset to the prior mark,
> effectively backtracking the single failed repetition and keep all successful
> repetitions of the array. However, if an error occurs during a repetition and
> a discriminator *IS* set, then we backtrack the entire array back to the
> startState mark.
> This behavior is not correct. This behavior treats the beginning of an array
> as if it were a point of uncertainty, but that is not the case. Only each
> element of the array is a point of uncertainty. So there is no need for the
> startState mark. It should be removed, and if a repetition fails and a
> discriminator is set then we should simply discard priorState mark and
> backtrack to whatever point of uncertainty enclosed the array (i.e. just
> return from the parse call and let containing parsers handle it).
> We should also examine the other repetition parsers and ensure they have the
> correct behavior.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
