ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
0007116Part 01: TTCN-3 Core LanguageTechnicalpublic28-07-2015 14:3114-10-2015 12:44
Tomas Urban 
Gyorgy Rethy 
normalminorhave not tried
closedfixed 
v4.7.1 (published 2015-06) 
v4.8.1 (published 2016-07)v4.8.1 (published 2016-07) 
5.4.2
STF 487
0007116: Actual parameters of out formal template parameters
Variables and formal value parameters should not be mentioned in the following rule:

Actual parameters that are passed to out formal template parameters shall be variables, template variables, formal value parameters, formal template parameters or references to elements of variables, template variables, formal value parameters or formal template parameters of structured types.

That's because it allows to assign template to value. Consider the following example:

Actual parameters that are passed to out formal template parameters shall be template variables, formal template parameters or references to elements of template variables or formal template parameters of structured types.

function f(out template integer p) {
  p := ?;
}

control {
  var integer v;
  f(v); // after the function call, v would contain a matching symbol!!!
}

Proposal: Change the rule to:
No tags attached.
related to 0007114closed Gyorgy Rethy Actual parameters of out formal value parameters not defined 
Issue History
28-07-2015 14:31Tomas UrbanNew Issue
29-07-2015 11:39Tomas UrbanNote Added: 0013009
30-07-2015 10:04Tomas UrbanNote Added: 0013010
03-08-2015 10:46Gyorgy RethyNote Added: 0013019
03-08-2015 10:46Gyorgy RethyAssigned To => Gyorgy Rethy
03-08-2015 10:46Gyorgy RethyStatusnew => assigned
03-08-2015 10:53Tomas UrbanNote Added: 0013021
04-08-2015 11:21Gyorgy RethyNote Edited: 0013019bug_revision_view_page.php?bugnote_id=13019#r139
04-08-2015 11:40Gyorgy RethyNote Added: 0013054
04-08-2015 11:54Gyorgy RethyNote Added: 0013056
04-08-2015 12:56Gyorgy RethyNote Edited: 0013056bug_revision_view_page.php?bugnote_id=13056#r141
04-08-2015 14:58Jacob Wieland - SpirentNote Added: 0013069
06-08-2015 10:16Gyorgy RethyRelationship addedrelated to 0007114
07-08-2015 09:05Jacob Wieland - SpirentStatusassigned => confirmed
25-09-2015 10:58Gyorgy RethyTarget Version => v4.8.1 (published 2016-07)
14-10-2015 12:44Gyorgy RethyNote Added: 0013385
14-10-2015 12:44Gyorgy RethyNote Added: 0013386
14-10-2015 12:44Gyorgy RethyStatusconfirmed => closed
14-10-2015 12:44Gyorgy RethyResolutionopen => fixed
14-10-2015 12:44Gyorgy RethyFixed in Version => v4.8.1 (published 2016-07)

Notes
(0013009)
Tomas Urban   
29-07-2015 11:39   
The changed rule should be:
Actual parameters that are passed to out formal template parameters shall be template variables, formal template parameters or references to elements of template variables or formal template parameters of structured types.
(0013010)
Tomas Urban   
30-07-2015 10:04   
It should be also possible to use references to string items as actual parameters of out formal value parameters.

Example:

function f (out charstring p_out) {
   p_out := "r";
}

control {
  var charstring v_str := "test";
  f(v_str[0]); // similar to assignment such as v_str[0] := "r"
  log(v_str); // prints "rest"
}
(0013019)
Gyorgy Rethy   
03-08-2015 10:46   
(edited on: 04-08-2015 11:21)
STF discussion 03-08-2015: Could be a potentially backward incompatible change. Ask tool vendors; send out a simple example code and ask for the result.

(0013021)
Tomas Urban   
03-08-2015 10:53   
Just a note: In case the STF decides that the references are resolved at the moment of passing of the formal parameter value to the actual parameter (i.e. this is the moment of passing the actual parameter to the formal parameter), the following rule has to be changed so that it doesn't include out parameters anymore: The actual parameters are evaluated in the order of their appearance.
(0013054)
Gyorgy Rethy   
04-08-2015 11:40   
I think your comment is partly correct, I would say the rule should be refined:
- in fact, the actual parameter itself passed to an out parameter shall not be evaluated when entering the called function (it shall not be an expression anyway, just a "bare" variable that will be overwritten, so evaluating it or not "theoretically", doesn't change anything)
- but if the actual parameter is a member of an array (of any kind), than the index has to be evaluated to know, which array member is the actual actual :-) parameter; there is no reason to make this evaluation in another order than the general parameter evaluation.
(0013056)
Gyorgy Rethy   
04-08-2015 11:54   
(edited on: 04-08-2015 12:56)
Looking at the CR again, in more detail, in fact the question is if we allow passing value variables to template formal parameters?
If yes,
- it may cause runtime error when trying returning a matching mechanism from the function,
- or an implicit valueof if the formal parameter returns a concrete value,
but is backward compatible, as this is not forbidden today.
- and this is true for inout parameters as well...

But if all tools are so cautious that forbids this at the semantic check level, it can also be made explicit in the standard.

One way or another, but some clarification will be needed...

(0013069)
Jacob Wieland - Spirent   
04-08-2015 14:58   
I have addressed these issues also in the CR 7114 resolution proposal.

But, of course, because of the possible backward incompatibility (in case that an out parameter is declared as template but always filled with a value when used with an actual value parameter), we should still ask the tool vendors about this.

Basically, it should DEFINITELY be an error if an actual value parameter is used for a template formal parameter which is assigned a matching mechanism. The question is only, if it is rejected at compile-time just on the basis of the parameter and type declarations or other inferrable means or if it is rejected at runtime when the out-parameter-template is assigned back to the actual-value-parameter.
(0013385)
Gyorgy Rethy   
14-10-2015 12:44   
Resolved by CR 7114 already
(0013386)
Gyorgy Rethy   
14-10-2015 12:44   
Resolved by CR 7114.