Hello,
While reading the ttcn-3 core language spec I was irritated by what can
be used as template for the "from" part of the receive statement.
Especially regarding internal addressing with component references.
One example in the spec allows a null component reference to be used
(ETSI ES 201 873-1 V4.3.1 (2011-06) page 56, Example 4):

var M1 MyMessage, MyResult;
var MyCompType1 MyInst1 := null;
var MyCompType2 MyInst2 := null;
var MyCompType3 MyInst3 := null;
:
alt {
[] PCO1.receive(M1:?) from MyInst1 -> value MyMessage sender MyInst1 {}
[] PCO1.receive(M1:?) from MyInst2 -> value MyMessage sender MyInst2 {}
[] PCO1.receive(M1:?) from MyInst3 -> value MyMessage sender MyInst3 {}
}

My understanding here would be that messages of type M1 are only then
received if the sender is "null" which of course will never happen.
To me it looks like "null" results into MyCompType:?
So my question is:
a)is it actually legal to insert a null reference into a "receive
from" statement?
b) is inserting of "MyCompType:?" legal ttcn-3 ?

BR.,

Uwe Truetsch

Hello,

This is a good question!

Unfortunately, the standard leaves the answer to it wide open:

The BNF explicitly allows InlineTemplate in the FromClause, so
syntactically any matching mechanism could be allowed here.

The table restricting matching mechanisms does not mention component
types (also not default types) so it is unclear if the table simply does
not restrict matching mechanisms for this type or if it does not
explicitly allow any for component types. Since the standard normally
forbids something by explicitly restricting it, and taking the BNF into
account, I would assume that matching mechanisms for component types
should be allowed. Of course, only Instead-of-Value matching mechanisms
make sense here.

Since the special value 'null' seems to be present in any component
type, the template MyCompType:? should also match for 'null'. But, as
you have correctly pointed out, since the sender never can be 'null',
this is a non-issue in case of the FromClause. Explicitly using
MyCompType:null would simply be a case of an alternative which can never
match (which cannot be avoided in general anyway) - it would be like
disallowing if (false) { ... }. It is more a tool-issue how the tool
deals with such situations.

The example in the standard is either simply a bit confusing (if one
assumes that the component variables have been assigned some specific
component references before entering the alt-statement) or simply wrong
or non-sensical (if the variables still contain the null-value). In the
first case, it does, of course not really make sense to assign the
sender to the same variable as is used in the FromClause as that would
always change nothing.

So, answering your question I would say, in my opinion, the standard
could be interpreted like this:

a) it is legal, but will cause an alternative which will never match
b) inserting MyCompType:? is legal and will match any sender component
of type MyCompType. For consistency's sake, subtypes of MyCompType are
probably forbidden as matching in receive-statements normally demands
strong typing. However, I also don't see any harm to allow all component
types compatible to MyCompType here.

In general, I think the standard is a bit vague in that respect and
should probably be clarified. Also, the example should be re-designed.

BR, Jacob Wieland

--

---

Dr. Jacob Wieland
Software Engineer

Testing Technologies IST GmbH
Michaelkirchstraße 17/18
10179 Berlin, Germany

Phone +49 30 726 19 19 34 Email This email address is being protected from spambots. You need JavaScript enabled to view it.
Fax +49 30 726 19 19 20 Internet www.testingtech.com

---

Geschäftsführung: Theofanis Vassiliou-Gioles, Stephan Pietsch
Handelsregister HRB 77805, Amtsgericht Charlottenburg
Ust ID Nr.: DE 813 143 070

This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.

Hi Uwe,

I cannot see any restriction on this respect, there fore both allowed. Of course, if the value of the address in the from clause is null, it will not match any component references existing in the system, therefore the receive operation will never succeed, whatever is the actual received message.

In-line templates are also allowed in from clauses, therefore you can also use MyCompType:? in the from clause. In short, basically the same matching algorithm is in place for the address in the from clause as matching the received message itself, limited, of course by the type of the address (component type); e.g. pattern, length, ifpresent etc. cannot be used.

BR, GYorgy

Hello Gyorgy, hello Jacob,
thanks for your replies. One action I would propose here is changing
this example in question to make it less ambiguous/ more meaningful,
e.g:

var M1 MyMessage, MyResult;
var MyCompType1 MyInst1 := null;
var MyCompType2 MyInst2 := null;
var MyCompType3 MyInst3 := null;
:
alt {
[] PCO1.receive(M1:?) from MyCompType1:? -> value MyMessage sender
MyInst1 {}
[] PCO1.receive(M1:?) from MyCompType2:? -> value MyMessage sender
MyInst2 {}
[] PCO1.receive(M1:?) from MyCompType3:? -> value MyMessage sender
MyInst3 {}
}

BR.,
Uwe

Hi Uwe,

pl. note the ":" between the declarations and the list of receive operations. This marks some more operations between the two blocks, i.e., during the receive operation the value of the MyInstX variables is not null. At least this is the intention of the example.

Pls. submit a CR to clarify this in the example (actually, the create operations may be done directly when declaring the comp. ref. variables).

BR, Gyorgy