[jira] [Commented] (DAFFODIL-1888) byteOrder bigEndian with bitOrder leastSignificantBitFirst combination

["Marshall Miller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DAFFODIL-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16546985#comment-16546985 ] 

Marshall Miller commented on DAFFODIL-1888:
-------------------------------------------

I squashed my commits and rebased on master.  The commit hash for my changes is bea965e055aeb5aeb2e324b6df4020edf5d9c6e0.

> byteOrder bigEndian with bitOrder leastSignificantBitFirst combination
> ----------------------------------------------------------------------
>
>                 Key: DAFFODIL-1888
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-1888
>             Project: Daffodil
>          Issue Type: New Feature
>          Components: Back End, Front End
>            Reporter: Michael Beckerle
>            Assignee: Marshall Miller
>            Priority: Minor
>             Fix For: deferred
>
>
> The SISO-J data format requires the 4th combination of byteOrder and bitOrder which DFDL v1.0 currently disallows. DFDL workgroup discussions suggest this restriction will just be lifted. 
> This is a good feature for someone new to Daffodil to implement.
> This format, which is a envelope format for an envelope-and-payload style of data, describes data as bigEndian, but LSBF.
> https://www.sisostds.org/DesktopModules/Bring2mind/DMX/Download.aspx?Command=Core_Download&EntryId=43048&PortalId=0&TabId=105
> Thanks to Marshall Miller of Quark Security for this insight. This item extracted from the dev@daffodil.apache.org mailing list.
> One can workaround this problem in Daffodil by way of dfdl:inputValueCalc/dfdl:outputValueCalc and hidden groups. But that is, perhaps, unsatisfying.
> Example:
> Data is comprised of 3 unsigned integer bitfields:
> slot1 is 12 bits
> slot2 is 32 bits
> slot3 is 20 bits
> Given an input with the following bytes in hex:
> 01 23 45 67 89 AB CD EF
> Parsed results need to be (in hex):
> slot1: 0567
> slot2: DEF01234
> slot3: 089ABC
> Explanation of results:
> Since the bit fields need to consume data in a leastSignificantBitFirst
> order, it is easier to represent the input in right-to-left order
> where bits are consumed starting at the right and moving toward the
> left.  Since words are 4 bytes, and in big endian order, the lowest
> bit in the 4th byte is the first bit to be consumed.  Reordering the
> input data and consuming data from right to left yields the correct
> field boundaries.
> 89 AB CD EF 01 23 45 67      parse fields right to left
> 05 06 07 08 01 02 03 04      input byte position
> slot1 consumes the right 3 nibbles, slot2 consumes the next 8 nibbles,
> and slot3 consumes the left 5 nibbles.



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