Page History

...

• One layer of the protocol stack is fixed to a given endianess (UDP is Big Endian, for example, PROFINET IO CM Blocks are Big Endian too)
• Endianess of fields are dependent on some parsed values (In DCE/RPC there is a 4 bit field, that controlls if the following fields are BigEndian or LittleEndian)
• Endianess of all fields of a complex type are dependent on the endianess of the parent (In case of PROFINET IO CM the ProfinetIO CM packet has the same endianess of the DCE/RPC packet that contains it)

In order to address this we discussed 3 options:

• Adding a new block type "endianessSwitch" which sets the endianess of the parser to a given endianess, and hereby reads all the fields it contains using this endianess and then returns back to it's original endianess when leaving the block
• We add a flag to fields that allow setting the endianess for parsing this field (and if it's a complex one ... all of it's children
• We add a flat to the type definition

All options have their advantage/disadvantage.

Adding a flag to the field would simply require us to come up with a sensible notation, which I haven't currently found anything I would feel comfortable with.

With adding a flag to a type: This seems simple, but how would we control this from the usage?

Chris' thoughs on this

I would propose implementing two of these aboe scenarios:

1. We define a new block type of "endianessSwitch" ... this can either take a constant "LE" or "BE" (Or the long form) ... or an expression which evaluates to one of the two.
2. We add the BE/LE flag to type definitions (explicitly no dynamic here)

Now to my reasoning:

Usually, it will not only be one field that needs to be switched, so adding a flag to the fields would require duplicating a lot of the flagging-code to the mspec documents. Using a block of equally endianed fields simplifies things. And in addition to that it explicitly focusses on the detail of setting the endianess, which should simplify implementing this in the code-generation ... as a endianessSwitch simply gets converted into an allmost constant try-finally block.

Not allowing dynamic switching in types and simply forcing this to be constant solves the problem of how the system tells the parser which endianess to use. 

So taking into account the 3 scenarios above. This would then be solved the following way:

 "One layer of the protocol stack is fixed to a given endianess" ... simply set UDP or the PROFINET IO CM Block type definitions to "BE".

"Endianess of fields are dependent on some parsed values" ... simply use a endinanessSwitch.

"Endianess of all fields of a complex type are dependent on the endianess of the parent" if the type definition doesn't have any BE/LE flags, it simply uses the endianess of the parent.