RAW codec: Odd behavior of PADDING attribute
Submitted by Vadim Yanitskiy
Created attachment 282713 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  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.
Attachment 282713, "Test module demonstrating the problem":