Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » concatenating templates of list types
concatenating templates of list types [message #1780794] Sat, 27 January 2018 14:31 Go to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 47
Registered: July 2017
Location: Berlin, Germany
Member

ES 201 873-1 Section 15.11 states that templates of list types can be concatenated.

However, I'm having trouble doing this in TITAN.

Are there any known restrictions? I'm getting the following compiler error from TITAN 6.3.0, which seems to hint that the '&' operator expects values, not templates:

   GSUP_Types.ttcn:221.9-18: In the left operand of operation `&':
    GSUP_Types.ttcn:221.9-11: error: Reference to a value was expected instead of template parameter `ies'
   GSUP_Types.ttcn:221.9-18: In the right operand of operation `&':
    GSUP_Types.ttcn:221.16-17: In component #1:
     GSUP_Types.ttcn:221.16-17: error: Reference to a value was expected instead of template parameter `ie'


I couldn't find any mention in the TITAN reference guide / programmer manual on any such restriction. Thanks!
Re: concatenating templates of list types [message #1780845 is a reply to message #1780794] Mon, 29 January 2018 08:13 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 759
Registered: January 2015
Senior Member
Hi Harald,

parameters passed to a template are considered value parameters unless
declared otherwise.


Hence

template  GSUP_PDU ts_GSUP_CL_REQ(hexstring imsi, GSUP_CancelType ctype) :=
	ts_GSUP(OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST, { ts_GSUP_IE_IMSI(imsi), ts_GSUP_IE_CancelType(ctype) });


template GSUP_PDU ts_GSUP(GSUP_MessageType msgt, GSUP_IEs ies := {}) := {
	msg_type := msgt,
	ies := ies
}


template  GSUP_IE ts_GSUP_IE_CancelType(GSUP_CancelType ctype) := {
	tag := OSMO_GSUP_CANCEL_TYPE_IE,
	len := 0, /* overwritten */
	val := {
		cancel_type := ctype
	}
}


template GSUP_IE ts_GSUP_IE_IMSI(hexstring imsi) := {
	tag := OSMO_GSUP_IMSI_IE,
	len := 0, /* overwritten */
	val := {
		imsi := imsi
	}
}


will not work , as Titan needs to convert ts_GSUP_IE_CancelType, ts_GSUP_IE_IMSI to values,


but

template  GSUP_PDU ts_GSUP_CL_REQ(hexstring imsi, GSUP_CancelType ctype) :=
	ts_GSUP(OSMO_GSUP_MSGT_LOCATION_CANCEL_REQUEST, { ts_GSUP_IE_IMSI(imsi), ts_GSUP_IE_CancelType(ctype) });


template GSUP_PDU ts_GSUP(GSUP_MessageType msgt, template GSUP_IEs ies := {}) := {
	msg_type := msgt,
	ies := ies
}


template  GSUP_IE ts_GSUP_IE_CancelType(GSUP_CancelType ctype) := {
	tag := OSMO_GSUP_CANCEL_TYPE_IE,
	len := 0, /* overwritten */
	val := {
		cancel_type := ctype
	}
}


template GSUP_IE ts_GSUP_IE_IMSI(hexstring imsi) := {
	tag := OSMO_GSUP_IMSI_IE,
	len := 0, /* overwritten */
	val := {
		imsi := imsi
	}
}





will. Note that I have changed the type of parameter GSUP_IEs ies := {} in
ts_GSUP to template



I hope this clarifies it.

Best regards

Elemer

Re: concatenating templates of list types [message #1781022 is a reply to message #1780845] Wed, 31 January 2018 16:04 Go to previous messageGo to next message
Harald Welte is currently offline Harald WelteFriend
Messages: 47
Registered: July 2017
Location: Berlin, Germany
Member

Thanks. It's actually easy enough I could have figured it out myself :/

I always try to use template arguments only in receive templates, but use value arguments in send templates. But that general rule of thumb of course doesn't work here, and I understand *why* it behaves the way you described.

btw: What I find conceptually difficult to accept is that I can declare a template with (value) restriction, and hence the template can always only have a "fully qualified value", but then I still need to use valueof() that (value) template. But then, that's just how the language is specified, no use of me complaining about my personal usability concerns here ;)
Re: concatenating templates of list types [message #1781070 is a reply to message #1781022] Thu, 01 February 2018 07:46 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 759
Registered: January 2015
Senior Member
Hi Harald,

I see you point , of course the compiler could automatically invoke value conversion; however there's an approach I 'd recommend you:

The language itself was not meant for programmers but for protocol experts who don't necessarily have a strong background in programming; their primary focus is the node or
protocol under investigation. Hence the code, distributed in source, should be as straightforward, easily readable and unequivocal as possible. There's no room for obfuscation and each step
has to be marked clearly. Any unnecessary complication is just an unwanted irritation for the user.
In some points Titan even surpasses the standard in this respect : we prefer that everything happens aboveboard, in an explicit manner.

I myself prefer to think of TTCN-3 as a protocol analyzer/generator disguised in the form of a programming language. This is a good argument when trying to disarm those developers that question even the right to existence of the language, pointing out features that from their point of view appear to be missing.



Best regards
Elemer


Previous Topic:avoiding warnings about unused function arguments
Next Topic:'ifpresent' or ternary operator in parametric send templates
Goto Forum:
  


Current Time: Thu Jun 21 22:16:52 GMT 2018

Powered by FUDForum. Page generated in 0.01756 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top