[jira] [Assigned] (DAFFODIL-2069) Unparser interaction of outputValueCalc with hexBinary with following bitOrder LSBF element.

["Steve Lawrence (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DAFFODIL-2069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Lawrence reassigned DAFFODIL-2069:
----------------------------------------

    Assignee: Steve Lawrence

> Unparser interaction of outputValueCalc with hexBinary with following bitOrder LSBF element.
> --------------------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2069
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2069
>             Project: Daffodil
>          Issue Type: Bug
>          Components: Back End
>    Affects Versions: 2.3.0
>            Reporter: Michael Beckerle
>            Assignee: Steve Lawrence
>            Priority: Major
>             Fix For: 2.3.0
>
>          Time Spent: 50m
>  Remaining Estimate: 0h
>
> I don't know if we should block release 2.3.0 for this fix or not.
> It seems like a quite serious issue. It was discovered because one of the unit tests of mil-std-2045 schema fails now on the 2.3.0-RC1. test_2045msghdr2 fails now.
> I isolated this and created a test in daffodil-test module.
> When in bitOrder="leastSignificantBitFirst", a hexBinary element seems to interact with the following element, but only in the case where there is an outputValueCalc.
> The situation occurs when you have a length element which has an OVC that gets the valueLength of a hexBinary element following it. In this case, parsing works fine, but unparsing it seems that the bitOrder LSBF after the hexBinary element is lost. The bits are positioned in MSBF position, not LSBF.
> If you replace the hexBinary element with a string, the problem does not occur.
> See test test_ovcHexBinaryLSBF1
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)