Community
Participate
Working Groups
Created attachment 282713 [details] Test module demonstrating the problem For a long time I've been facing odd and unpredictable behavior of the 'PADDING' attribute, so finally I found some time and came up with a test module demonstrating it. Please see the attachment. In that module I basically define three different messages: * MessageType1 - always occupies 6 octets (no padding), * MessageType2 - shall be aligned to 8 octets ('2B'O padding), * MessageType3 - shall be aligned to 13 octets ('2B'O padding), which are then grouped into a union 'MessagePayload' and prefixed with a simple header. Unlike the first message, both second and third contain a flexible octetstring called 'rest_octets' at the end with variable length. So the actual contents of the 'rest_octets' may be shorter or even omitted (i.e. an empty octetstring). Regardless of the actual length of the 'rest_octets', both second and third messages shall be aligned to 8 and 13 octets respectively. This is what I am trying to achieve using the PADDING attributes. Note that I cannot apply padding to the final record combining the message header and the payload, because of the length constraints mentioned above. For the sake of diversity, in case of the second message I applied padding to the whole record. For the third message, the padding is applied directly to the 'rest_octets'. Unfortunately, neither of this variants works as expected. Because of that, on practice [1][2][3] I have to work this around by adding / stripping padding bytes manually. Interestingly enough, this (mis)behavior is not observed when padding is applied to a top-level record that is passed to the RAW codec, i.e. the 'Message' in this example. But as I stated, this is not what I need. [1] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/18026 [2] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15571 [3] https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15488
The reference point of the padding attribute is the beginning of the message, not the beginning of the type/field applied on. So the size of the whole message, including the header is considered when the padding was applied. It is stated in the documentation: "Description: This attribute specifies that an encoded type shall end at a boundary fixed by a multiple of padding unit bits counted from the beginning of the message." Yes, we know this is a limitation of the RAW encoder, and the more flexible padding implementation is on the to do list.
This looks like a new feature request aiming to make the RAW coder more flexible.
This bug was migrated to GitLab: https://gitlab.eclipse.org/eclipse/titan/titan.core/-/issues
