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

Mike Beckerle commented on DAFFODIL-2689:
-----------------------------------------

Marked with label beginner, not because this issue is really all that small a 
piece of code, but because there are the other 3 combinations of 
bitOrder/byteOrder already in the code base, so it should be relatively easy to 
follow the pattern and fill in the 4th combination. 

> Asterix format uses DFDL disallowed 4th combination of byte order and bit 
> order
> -------------------------------------------------------------------------------
>
>                 Key: DAFFODIL-2689
>                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2689
>             Project: Daffodil
>          Issue Type: New Feature
>          Components: Back End, Front End
>    Affects Versions: 3.3.0
>            Reporter: Mike Beckerle
>            Priority: Major
>              Labels: beginner
>         Attachments: image-2022-04-13-11-10-28-938.png
>
>
> The Asterix CAT 034 message uses byteOrder bigEndian but bit order 
> leastSignificantBitFirst for numbers that span bytes. For example they 
> describe an 11-bit integer in this way:
> !image-2022-04-13-11-10-28-938.png!
> In this picture you can see they are numbering the bits from the right, 
> leastSignificantBitFirst starting from 1. But the COUNTER field spans all of 
> Octet 3, but also includes the least significant 3 bits of Octet 2. In those 
> least significant 3 bits are the most significant (numerically) 3 bits of the 
> 11 bit COUNTER integer, so this is bigEndian byte order, but 
> leastSignificantBitFirst bit order.
> The DFDL standard does not allow this combination of bitOrder and byteOrder, 
> as there was no known documented use case at the time the new bitOrder 
> property was added to the DFDL specification. It was however, proposed that 
> it was likely this combination would be needed, and here is a well-documented 
> use case. 
> So Daffodil should lift this restriction and allow this combination.
> The workaround in the mean time is to parse this counter as two separate 
> integers, one 3 bits and one 8 bits, and use an inputValueCalc expression to 
> compute a field with the expected value. 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

Reply via email to