Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » Compile-time vs. run-time verifications in Titan
Compile-time vs. run-time verifications in Titan [message #1746065] Fri, 21 October 2016 09:09
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 758
Registered: January 2015
Senior Member
OK, let's just take a look at the following expression:

 type octetstring OCT1 length(1) with { variant "FIELDLENGTH(1)" };


This expression contains two sets of instructions , one addressed to the compiler
( length(1) , a subtyping information for octetstring)
and one addressed to the RAW codec
( with { variant "FIELDLENGTH(1)" } ).

(From this only is not obvious that is addressed to the RAW codec, but I know that the file I have taken this line form contains a
final "with { encoding "RAW" }" instruction).


-lenght(1) tells the compiler that any variable etc. of this type should be an octetstring of length one exactly.
-with { variant "FIELDLENGTH(1)" } tells the encoder/decoder that any variable etc. of this type when binary encoded should be encoded into an octetstring of length one exactly.

Although this may appear redundant , it is not:

 type octetstring OCT1 length(1) with { variant "FIELDLENGTH(4)" };


is also perfectly valid as I might have a variable of length one octet I may want to encode into four octets by adding zeroes in front; this is nothing unheard of.


The instructions addressed to the codec will be checked and enforced during encoding/decoding , that is during execution, or run-time, as the only possible option.


During compilation, the compiler performs a rather accurate semantic verification of the code and rejects anything in violation of the language rules.
Take this code as an example:

module test
{

  type octetstring OCT1 length(1) with { variant "FIELDLENGTH(1)" };

control	{

var OCT1 v_pduformat   

v_pduformat:='000000AA'O; // this is detected and rejected compile-time 

log("v_pduformat>>>>>>>",v_pduformat)

		}

}


The compiler will refuse to generate code for the next step as v_pduformat is clearly in violation of subtyping rules.
However some language constructs such as functions cannot be evaluated run-time: function can have parameters of which values may be taken from the configuration file or from data incoming on a test port which makes their return unpredictable at the moment of compilation.

So next to compile-time checking a run-time checking will ensure total consistency; but this also means that the executing code has to take a high number of computationally intensive decisions on the fly which takes its' toll on the execution speed. Due to this, run-time checking in Titan has been reduced to the bare minimum.



As a result, this code
module test2
{

type octetstring OCT1 length(1) with { variant "FIELDLENGTH(1)" };


function f_pduformat() return octetstring
	{
	return '000000AA'O;
	}
control	{
	var OCT1 v_pduformat   
	v_pduformat:=f_pduformat(); //this should be detected runtime as subtyping error
	log("v_pduformat>>>>>>>",v_pduformat)

		}
}

will evade both compile-time and run-time verification ( OK, in this case the compiler could calculate the function return, but this is an atypically simplistic example the function having no parameter)


This -deliberate- compromise seems to blow a major whole in Titan consistency; in real life though, this should not cause problems as there are several other checkpoints where subtyping violation will be penalized: during encoding/decoding (which is a compulsory step when talking to an SUT), template matching etc.


The reason I brought this up though is to avoid confusing moments when Titan seems to perform inappropriately. If one is aware of the peculiarities of the tool it's easier to get in control of it.

Best regards
Elemer
Previous Topic:Advanced TTCN-3 usage: the secret life of assignments
Next Topic: Titanized ETSI ITS Test suites: Critical bug fixed in JAVA files
Goto Forum:
  


Current Time: Thu Jun 21 01:03:22 GMT 2018

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

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

Back to the top