This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/gerrit-log@lists.osmocom.org/.
Vadim Yanitskiy gerrit-no-reply at lists.osmocom.orgVadim Yanitskiy has uploaded this change for review. ( https://gerrit.osmocom.org/14073 Change subject: library/PCUIF_Types.ttcn: add explicit ALIGN(left) attribute ...................................................................... library/PCUIF_Types.ttcn: add explicit ALIGN(left) attribute In the documentation of Eclipse Titan compiler before [1] it was clearly stated that if the length of the actual value can be determined and it is less than the specified FIELDLENGTH, the remaining bits / bytes will be padded with zeros. The attribute ALIGN specifies the sequence of the actual value and the padding within the encoded field: Attribute syntax: ALIGN(<parameter>); Parameters allowed: left, right; Default value: 'right'. Since [1], the default value is: 'left' for octetstrings, 'right' for all other types. [1] https://github.com/eclipse/titan.core/commit/3cbafbd31d5f79049afbf69f8dcba0b94cbf20b2 In the most 'BTS_Tests.TC_pcu_*', including both 'TC_pcu_data_req_agch' and 'TC_pcu_data_req_imm_ass_pch' we do pass the payload of length 23 bytes to ts_PCUIF_DATA_REQ(), what is less than the actual field length (162 bytes). Thus when using titan.core <= 6.5.3, the payload appears at the end of the buffer on the BTS side, so it reads 23 zero-bytes from the beginning and does transmit them. Let's explicitly add ALIGN(left) to field 'data' of 'PCUIF_data', so the alignment would be done correctly, as expected by the BTS. Let's also drop 'OCT162' type, as it doesn't make sense outside the message definition. This change makes the following test cases pass: - 'TC_pcu_data_req_agch' and - 'TC_pcu_data_req_imm_ass_pch'. Change-Id: Ic4f358e5053e30e0dd7be8b6ac9c1d86cf9d8065 --- M library/PCUIF_Types.ttcn 1 file changed, 4 insertions(+), 6 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-ttcn3-hacks refs/changes/73/14073/1 diff --git a/library/PCUIF_Types.ttcn b/library/PCUIF_Types.ttcn index 17adbd1..750e0b4 100644 --- a/library/PCUIF_Types.ttcn +++ b/library/PCUIF_Types.ttcn @@ -67,12 +67,10 @@ PCUIF_Text text } with { variant "" }; -type octetstring OCT162 length(162) with { variant "FIELDLENGTH(162)" }; - type record PCUIF_data { PCUIF_Sapi sapi, uint8_t len, - OCT162 data, + octetstring data length(162), uint32_t fn, uint16_t arfcn, uint8_t trx_nr, @@ -82,7 +80,7 @@ uint16_t ber10k, int16_t ta_offs_qbits, int16_t lqual_cb -} with { variant "" }; +} with { variant (data) "FIELDLENGTH(162), ALIGN(left)" }; type record PCUIF_data_cnf_dt { PCUIF_Sapi sapi, @@ -373,7 +371,7 @@ template (value) uint8_t ts_nr, template (value) uint8_t block_nr, template (value) PCUIF_Sapi sapi, - template (value) OCT162 data, + template (value) octetstring data, template (value) uint32_t fn, template (value) uint16_t arfcn, template (value) int8_t rssi := -80, @@ -405,7 +403,7 @@ template uint8_t ts_nr := ?, template uint8_t block_nr := ?, template PCUIF_Sapi sapi := ?, - template OCT162 data := ?) := { + template octetstring data := ?) := { msg_type := PCU_IF_MSG_DATA_IND, bts_nr := bts_nr, spare := ?, -- To view, visit https://gerrit.osmocom.org/14073 To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-MessageType: newchange Gerrit-Change-Id: Ic4f358e5053e30e0dd7be8b6ac9c1d86cf9d8065 Gerrit-Change-Number: 14073 Gerrit-PatchSet: 1 Gerrit-Owner: Vadim Yanitskiy <axilirator at gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/gerrit-log/attachments/20190516/38899ff7/attachment.htm>