Change in ...osmo-ttcn3-hacks[master]: library/PCUIF_Types.ttcn: inform RAW codec about PADDING in PCUIF_data

[laforge]

laforge has submitted this change and it was merged. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15409 )

Change subject: library/PCUIF_Types.ttcn: inform RAW codec about PADDING in PCUIF_data
......................................................................

library/PCUIF_Types.ttcn: inform RAW codec about PADDING in PCUIF_data

PADDING is one of the TITAN specific language extensions [1], which
tells the RAW codec that an encoded payload shall end at a boundary
fixed by a multiple of 'padding' unit bits counted from the
beginning of the message.

Let's use it for record 'PCUIF_data', where the fixed-size buffer
is located in between the other fields, so padding will be ignored
by the RAW coding after decoding:

  $HOST: dec_PCUIF_Message(): Decoded @PCUIF_Types.PCUIF_Message: {
    msg_type := PCU_IF_MSG_DATA_REQ (0),
    bts_nr := 0, spare := '0000'O,
    u := {
      data_req := {
        sapi := PCU_IF_SAPI_AGCH (2),
	len := 23,
	data := '2D063F100FE3673A096B0000C800300B2B2B2B2B2B2B2B',
	...
      }
    }
  }

As a result, we don't have to deal with padding manually and
can safely use 'decmatch' statement in the receive templates.

[1] usrguide/referenceguide/4-ttcn3_language_extensions.adoc

Change-Id: I5808954b5c67c3239e795e43ae77035152d359ef
---
M library/PCUIF_Types.ttcn
1 file changed, 7 insertions(+), 2 deletions(-)

Approvals:
  Jenkins Builder: Verified
  laforge: Looks good to me, approved
  osmith: Looks good to me, but someone else must approve
  pespin: Looks good to me, but someone else must approve



diff --git a/library/PCUIF_Types.ttcn b/library/PCUIF_Types.ttcn
index 132b72d..551081b 100644
--- a/library/PCUIF_Types.ttcn
+++ b/library/PCUIF_Types.ttcn
@@ -76,10 +76,15 @@
 	PCUIF_Text	text
 } with { variant "" };
 
+/* This is a bad side of the current protocol design: fixed-size buffer is located
+ * in between the other fields of the message, so if the payload is smaller than
+ * 162 octets (1296 bits), we need to fill the remaining space with padding. */
+type octetstring PCUIF_DataPad with { variant "ALIGN(left), PADDING(1296)" };
+
 type record PCUIF_data {
 	PCUIF_Sapi	sapi,
 	uint8_t		len,
-	octetstring	data length(162),
+	PCUIF_DataPad	data,
 	uint32_t	fn,
 	uint16_t	arfcn,
 	uint8_t		trx_nr,
@@ -89,7 +94,7 @@
 	uint16_t	ber10k,
 	int16_t		ta_offs_qbits,
 	int16_t		lqual_cb
-} with { variant (data) "FIELDLENGTH(162), ALIGN(left)" };
+} with { variant (len) "LENGTHTO(data)" };
 
 type record PCUIF_data_cnf_dt {
 	PCUIF_Sapi	sapi,

-- 
To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/15409
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings

Gerrit-Project: osmo-ttcn3-hacks
Gerrit-Branch: master
Gerrit-Change-Id: I5808954b5c67c3239e795e43ae77035152d359ef
Gerrit-Change-Number: 15409
Gerrit-PatchSet: 2
Gerrit-Owner: fixeria <axilirator at gmail.com>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <axilirator at gmail.com>
Gerrit-Reviewer: laforge <laforge at gnumonks.org>
Gerrit-Reviewer: osmith <osmith at sysmocom.de>
Gerrit-Reviewer: pespin <pespin at sysmocom.de>
Gerrit-MessageType: merged
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190905/3e93a5bf/attachment.htm>