ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006318 | Part 01: TTCN-3 Core Language | Clarification | public | 21-09-2012 10:10 | 26-11-2013 16:57

Reporter | Tomas Urban |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.4.1 (published 2012-04) |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 8.2
Source (company - Author) | Elvior

Summary | 0006318: Assignment of global templates and module parameters

Description

I couldn't find any rules in the current standard saying when assignments of globally defined objects (i.e. static templates and module parameters) shall take place during execution. In my opinion, that gives vendors too much space for interpretation resulting in different approaches for executing such assignments, e.g.:
1. At the beginning of control part
2. When a global object is first referenced
3. At the beginning of the lowest block containing the first reference to a global object
Let's demonstrate it on an example:
module M
{
function f() return integer {
log("in function");
return 1;
}
template integer t := f();
type port P message{ inout integer; }
type component C { port P; }
testcase TC() runs on C {
log("in test case");
p.send(t);
}
control {
log("in control");
execute(TC());
}
}
In case of the first approach, the log would look like this:
in function
in control
in test case
In case of the second approach, thel log would lool like this:
in control
in test case
in function
In case of the third approach, thel log would lool like this:
in control
in function
in test case
If the first approach is used, then the global object declaration cannot contain calls that are not allowed in the control block. E.g. LTE test suite contains global templates that reference functions with testcase.stop inside and istantiating these templates in the control block can lead to trouble. This approach also makes unnecessary calls (instantiating templates that are actually never used).
If the second approach is used, then there's a danger that the template is referenced in a place mentioned in the chapter 16.1.4. In such a case it is possible that its declaration contains a function call that is forbidden by the restrictions listed in 16.1.4. If the template has been already referenced before, the statement will be executed without any problem (because the value has been already assigned and the forbidden function is actually not called). However, in case it is the first template reference, an error will occur during the function call. Such an approach is in my opinion unacceptable, because it can lead to different test case results that are dependent only on execution path.
The third approach doesn't suffer from any of the above mentioned problems, but it produces "unnatural" execution order and it might be difficult to explain it to users.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006606 | closed | Gyorgy Rethy | Allow usage of deterministic external functions in snapshot evaluation

Attached Files

CR-6318-resolution-V1.doc (70,144) 19-12-2012 13:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=2789&type=bug
CR-6318-resolution-V2.doc (70,656) 21-12-2012 12:06
http://oldforge.etsi.org/mantis/file_download.php?file_id=2798&type=bug
CR6318-Resolution-V3-JG.doc (90,624) 30-08-2013 10:35
http://oldforge.etsi.org/mantis/file_download.php?file_id=2880&type=bug
CR6318-Resolution-V4-JW.doc (89,600) 30-08-2013 13:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2881&type=bug
CR6318-Resolution-V5.doc (89,600) 10-10-2013 10:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=2918&type=bug

Issue History
Date Modified | Username | Field | Change
21-09-2012 10:10 | Tomas Urban | New Issue |
21-09-2012 10:10 | Tomas Urban | Clause Reference(s) | => 8.2
21-09-2012 10:10 | Tomas Urban | Source (company - Author) | => Elvior
28-09-2012 12:09 | Jacob Wieland - Spirent | Note Added: 0011154 |
10-12-2012 13:38 | Gyorgy Rethy | Status | new => assigned
10-12-2012 13:38 | Gyorgy Rethy | Assigned To | => Jens Grabowski
10-12-2012 16:42 | Gyorgy Rethy | Target Version | => Edition 4.5.1
11-12-2012 10:14 | Jens Grabowski | Note Added: 0011213 |
11-12-2012 10:14 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
11-12-2012 13:07 | Tomas Urban | Note Added: 0011220 |
14-12-2012 07:50 | Tomas Urban | Note Added: 0011262 |
14-12-2012 07:50 | Tomas Urban | Assigned To | Tomas Urban => Jens Grabowski
14-12-2012 12:56 | Jacob Wieland - Spirent | Note Added: 0011279 |
14-12-2012 14:36 | Jens Grabowski | File Added: CR6014-resolution-v3.doc |
14-12-2012 14:37 | Jens Grabowski | Note Added: 0011282 |
14-12-2012 14:37 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
19-12-2012 13:49 | Jens Grabowski | File Deleted: CR6014-resolution-v3.doc |
19-12-2012 13:49 | Jens Grabowski | File Added: CR-6318-resolution-V1.doc |
20-12-2012 11:19 | Gyorgy Rethy | Note Added: 0011296 |
20-12-2012 11:19 | Gyorgy Rethy | Status | assigned => resolved
20-12-2012 11:19 | Gyorgy Rethy | Resolution | open => fixed
20-12-2012 11:19 | Gyorgy Rethy | Fixed in Version | => Edition 4.5.1
21-12-2012 10:56 | Gyorgy Rethy | Status | resolved => feedback
21-12-2012 10:56 | Gyorgy Rethy | Resolution | fixed => reopened
21-12-2012 10:57 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
21-12-2012 10:57 | Gyorgy Rethy | Status | feedback => resolved
21-12-2012 10:57 | Gyorgy Rethy | Resolution | reopened => fixed
21-12-2012 12:05 | Ina Schieferdecker | Note Added: 0011311 |
21-12-2012 12:06 | Ina Schieferdecker | File Added: CR-6318-resolution-V2.doc |
21-12-2012 12:06 | Ina Schieferdecker | Status | resolved => closed
04-01-2013 11:52 | Jacob Wieland - Spirent | Status | closed => feedback
04-01-2013 11:52 | Jacob Wieland - Spirent | Resolution | fixed => reopened
04-01-2013 11:52 | Jacob Wieland - Spirent | Note Added: 0011318 |
04-01-2013 12:03 | Ina Schieferdecker | Status | feedback => assigned
04-01-2013 12:03 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jens Grabowski
04-01-2013 12:04 | Ina Schieferdecker | Note Added: 0011319 |
18-01-2013 11:13 | Jacob Wieland - Spirent | Note Added: 0011323 |
14-05-2013 15:33 | Gyorgy Rethy | Target Version | Edition 4.5.1 => v4.7.1 (published 2015-06)
08-07-2013 18:18 | Gyorgy Rethy | Fixed in Version | v4.5.1 (published 2013-04) =>
29-08-2013 16:31 | Gyorgy Rethy | Note Added: 0011642 |
30-08-2013 10:35 | Jens Grabowski | File Added: CR6318-Resolution-V3-JG.doc |
30-08-2013 10:37 | Jens Grabowski | Note Added: 0011654 |
30-08-2013 10:37 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
30-08-2013 13:44 | Jacob Wieland - Spirent | File Added: CR6318-Resolution-V4-JW.doc |
30-08-2013 13:47 | Jacob Wieland - Spirent | Note Added: 0011659 |
30-08-2013 13:48 | Jacob Wieland - Spirent | Note Added: 0011660 |
30-08-2013 13:48 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-08-2013 13:48 | Jacob Wieland - Spirent | Status | assigned => confirmed
30-08-2013 14:14 | Gyorgy Rethy | Note Added: 0011663 |
30-08-2013 14:14 | Gyorgy Rethy | Status | confirmed => assigned
30-08-2013 14:14 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
30-08-2013 14:14 | Gyorgy Rethy | Status | assigned => confirmed
30-08-2013 16:04 | Jacob Wieland - Spirent | Note Added: 0011665 |
30-08-2013 16:19 | Jacob Wieland - Spirent | Status | confirmed => assigned
30-08-2013 16:19 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
30-08-2013 16:19 | Jacob Wieland - Spirent | Assigned To | Ina Schieferdecker => Gyorgy Rethy
09-10-2013 10:53 | Jacob Wieland - Spirent | Relationship added | related to 0006606
10-10-2013 10:00 | Gyorgy Rethy | File Added: CR6318-Resolution-V5.doc |
10-10-2013 10:02 | Gyorgy Rethy | Note Added: 0011744 |
10-10-2013 10:03 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
10-10-2013 10:03 | Gyorgy Rethy | Status | assigned => confirmed
10-10-2013 10:03 | Gyorgy Rethy | Resolution | reopened => fixed
10-10-2013 10:09 | Tomas Urban | Note Added: 0011745 |
10-10-2013 15:30 | Jacob Wieland - Spirent | Status | confirmed => assigned
10-10-2013 15:30 | Jacob Wieland - Spirent | Note Added: 0011757 |
10-10-2013 15:30 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
10-10-2013 15:30 | Jacob Wieland - Spirent | Status | assigned => confirmed
26-11-2013 16:56 | Ina Schieferdecker | Note Added: 0011839 |
26-11-2013 16:56 | Ina Schieferdecker | Status | confirmed => resolved
26-11-2013 16:56 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
26-11-2013 16:57 | Ina Schieferdecker | Status | resolved => closed

Notes

(0011154)
Jacob Wieland - Spirent
28-09-2012 12:09

Since global templates are like constants, they should normally not produce any behavior or side-effects. Therefore, the same restrictions as for the usage of functions during alt-guard-evaluation should be imposed.
With this approach, it becomes irrelevant when the template is instantiated whether early at module-loading time or lazy at first-usage.
If the use of a template shall produce a behavior, it should be parameterized and the behavior given as actual parameter. Then, the evaluation time is clearly the point of usage. This approach can even be used together with default parameter values.

(0011213)
Jens Grabowski
11-12-2012 10:14

Section "16.1.4 Invoking functions from specific places" defines the restrictions for the usage of functions during alt-guard evaluation.
If I interprete 16.1.4 correctly, then he same restrictions apply for invoking functions in templates, template fields, in-line templates or as actual parameters.
The text of 16.1.4 is:
"Value returning functions can be called in communication operations (in templates, template fields, in-line templates, or
as actual parameters), in guards of alt statements or altsteps (see clause 20.2), and in initializations of altstep local
definitions (see clause 16.2). To avoid side effects that cause changing the state of the component or the actual snapshot
and to prevent different results of subsequent evaluations on an unchanged snapshot, the following operations shall not
be used in functions called in the cases specified above:"
Thus, the solution provided by Jacob is already implemented in the standard. Assigned to Tomas to crosscheck.

(0011220)
Tomas Urban
11-12-2012 13:07

Jens, I am afraid that I cannot agree your conclusion. 16.1.4 sets restrictions on function calls used in three syntactical constructions: communication operations, guards and altstep local definitions. It doesn't set any restriction on global template definitions.
We could of course add "and in declarations of global templates" to the mentioned sentence ("Value returning functions ... "), but I don't think it can be done because of problems with backwards compatibility. In particular, I am sure that there are test suites that contain external function calls in global template definitions. Using the same restrictions as for alt guards means that such test suites would stop working. However, allowing external functions has unfortunately an unpleasant side efect: the order of global template assignments will start to matter and it will be required to specify rules for execution order.

(0011262)
Tomas Urban
14-12-2012 07:50

Assigned to Jens to implement the changes discussed at yesterday's meeting.

(0011279)
Jacob Wieland - Spirent
14-12-2012 12:56

I think the problem with external functions is that it is unknown whether they have side effects or not. Maybe a way should be introduced to declare an external function side-effect-free and then allowing these functions both inside templates as well as the other special function-invocation-places.

(0011282)
Jens Grabowski
14-12-2012 14:37

Proposal for Resolution uploaded. Assigned to GyÃ¶gy for crosschecking.

(0011296)
Gyorgy Rethy
20-12-2012 11:19

Its Ok with one typo: in the first inserted text "paramterization" should be parameterization (first e is missing)

(0011311)
Ina Schieferdecker
21-12-2012 12:05

Implemented with small editorials as in v2.

(0011318)
Jacob Wieland - Spirent
04-01-2013 11:52

Sorry, but the resolution is not understandable.
What does "the place of their declaration" mean for global templates in regard to their initialization TIME. Up till now, the order of global declarations (which are essentially unordered) does not imply any initialization order. Also, no restriction when these templates shall be initialized (or if at all) before their use exists. The whole point of this CR was to clarify this (if really necessary) to avoid divergences between tools.
This has not been achieved by the solution as the place of a declaration does not tell us anything about the time of its initialization.
Also, if one would assume that all global templates shall be initialized before execution, the proposed solution would mean that parameterized templates are partially initialized before execution and the fields affected by parameterization are initialized at the place of their use.
This, in my view, is completely unacceptable behavior. No one would expect this behavior and it is backward incompatible for parameterized templates that call external functions (but not with one of the parameters) and assume this function call is done for every new instance of the template.

(0011319)
Ina Schieferdecker
04-01-2013 12:04

Please check

(0011323)
Jacob Wieland - Spirent
18-01-2013 11:13

Counter proposal.
In my understanding, the only problem that really exists (in regard to this issue) is the question whether it should be allowed to use templates using not-allowed constructs in the snapshot-evaluation-part of an alt-statement (i.e. in the guard expression or in the event-part).
Since it is definitely more convenient to allow this, I would propose to specify that all instances of global templates that are referenced in the snapshot-evaluation part of an (explicit or implicit) alt statement must be instantiated at the latest before the first evaluation of the snapshot of that alt statement and should otherwise be instantiated in the order of the appearance of their usage (from left to right).
Otherwise standardizing the instantiation order of global templates has wide-ranging ramifications. First of all, a global order must be established (i.e. over all modules), as otherwise, the order of unrelated templates would still be arbitrary. This would force every tool to always instantiate all global templates even though they are potentially not used by any testcase that is being run, i.e. performance optimizations are not possible in that regard anymore.
This new proposed solution thus solves two problems. It allows usage of any template inside the snapshot-evaluation part and assigns (a new) clear semantic meaning to such usage. It also leaves possibilities for tools to optimize template instantiation in regard to the testcases being executed.
If the order of external function calls is relevant to the user, they should write the TTCN-3 code accordingly so that order is enforced (e.g. by parameterizing the templates with the results of such calls).
Also, this proposal has no backward compatibility drawbacks (unlike the other) as the semantics of behavior of functioning existing code is not affected by it.

(0011642)
Gyorgy Rethy
29-08-2013 16:31

STF discussion 2013-08-29: A text to be included into the templates clause saying that users are strongly advised to adhere to the restrictions of 16.1.4 (functions called at specific places) for all function calls inside global constants, templates and module parameters, to avoid non-deterministic behavior and const/template/modulepar values.
These limitations cannot be made mandatory for backward compatibility reason, hence the advice.
It is also agreed that external functions producing deterministic output will be allowed in 16.1.4.

(0011654)
Jens Grabowski
30-08-2013 10:37

Resolution in file "CR6318-Resolution-V3-JG.doc". Assigned to Jacob for cross-checking.

(0011659)
Jacob Wieland - Spirent
30-08-2013 13:47

Removed the changes to the paragraph describing the full speficiation/initialization of templates in their declaration. We agreed that that was unnecessary. Fixed typos (adviced -> advised) Made description of non-deterministic functions more explicit (also regarding out parameters).

(0011660)
Jacob Wieland - Spirent
30-08-2013 13:48

please review my changes

(0011663)
Gyorgy Rethy
30-08-2013 14:14

In general OK with me but one comment.
While clause 16.1.4 item j) disallows inout and out parameters, the new text of item e) says: "where the resulting values for actual inout or out parameters or the return value may differ for different invocations with the same actual in and inout parameters".
j) and new e) seems to be contradicting. It seems it would be enough to write: "where the return value may differ for different invocations with the same actual parameters"

(0011665)
Jacob Wieland - Spirent
30-08-2013 16:04

no, the calling of out/inout functions is only disallowed for the top-level call (note 8, I think). Inside a function, calling other functions with inout/out parameters is allowed. The same should be true for external functions to be consistent and therefore, the determinism also needs to be established for the inout/out parameters.

(0011744)
Gyorgy Rethy
10-10-2013 10:02

It is note 6; I have added to it in CR6318-Resolution-V5.doc that the non-recursivity is meant for restriction j) to be unambiguous in this. With this minor amendment it is OK with me. Tomas, Jacob, pls, check if the resolution is OK with you.

(0011745)
Tomas Urban
10-10-2013 10:09

Very elegant solution. It allows tool vendors to add proper warnings/errors (depending on compiler settings) in problematic cases and still preserves backwards compatibility. I like it.

(0011757)
Jacob Wieland - Spirent
10-10-2013 15:30

fine with me

(0011839)
Ina Schieferdecker
26-11-2013 16:56

as proposed