[
https://issues.apache.org/jira/browse/DAFFODIL-1595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Thompson closed DAFFODIL-1595.
-----------------------------------
Verified the specified commit (commit be5394d3f1385ee64fd6ade283a578eab1503a33)
is included in the latest pull from the daffodil repository.
Verified, via review, changes identified in the commit comment were
implemented.
Verified the added test does test for data too long for specified length.
> Check for data too long for specified length - missing
> ------------------------------------------------------
>
> Key: DAFFODIL-1595
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1595
> Project: Daffodil
> Issue Type: Bug
> Components: Back End, Diagnostics, QA, Unparsing
> Reporter: Mike Beckerle
> Assignee: Olabusayo Kilo
> Priority: Major
> Labels: reverify
> Fix For: 4.0.0
>
>
> Due to the out-of-order way that dfdl:outputValueCalc has to work, the way
> unparsers compute how long data is, that had to change.
> That results in the means by which the unparsers measure and detect that the
> data is too long, need to be different.
> Now, there used to be code in unparser primitives that did this checking, but
> such code can't work in general anymore.
> The place that has to do this checking now is centralized into the
> RightFill(simple types) and ElementUnused(complex type) unparsers. However,
> this check isn't implemented there.
> No tests fail, so either there aren't tests exercising this, or the ones that
> are exercising this just happen to run because they do not also exercise
> dfdl:outputValueCalc, so nothing out-of-order is happening, and so the older
> checking code is maybe still working in those specific cases?
> So two things (a) checking code needs to be added to RightFillUnparser and
> ElementUnusedUnparser to detect when data that cannot be truncated is being
> unparsed into a specified length that is too small for it (b) tests that
> create errors due to data too long need to be created which also use aspects
> of the unparser that force the DirectOrBufferedDatatOutputStream to be used
> underneath, so as to force this error to be detected.
> Part of (a) is removing the legacy checking code which is not general enough
> to work now, from the few unparser primitives where it appears (might be only
> one?)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
