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

ID | Project | Category | View Status | Date Submitted | Last Update
0006647 | Part 01: TTCN-3 Core Language | Technical | public | 18-10-2013 10:21 | 05-01-2015 17:41

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | high | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 21.3.2
Source (company - Author) | STF 470

Summary | 0006647: Additional restrictions for component.start

Description

In my opinion, the current restriction limiting the type of parameters of function used in a component start operation (21.3.2.b) should contain the default type too. That's because 6.2.8 limits the use of default values to the component of their origin. Passing a reference to a different component would only lead to problems, because any use of it in the started component would automatically lead to an error.
The updated rule should also mention that the parameters of the function shall not be of a structured type that contains fields of default or port type on any level of nesting.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6647.doc (287,232) 26-11-2013 14:31 http://oldforge.etsi.org/mantis/file_download.php?file_id=2941&type=bug

Issue History
Date Modified | Username | Field | Change
18-10-2013 10:21 | Tomas Urban | New Issue |
18-10-2013 10:21 | Tomas Urban | Clause Reference(s) | => 21.3.2
18-10-2013 10:21 | Tomas Urban | Source (company - Author) | => STF 470
18-10-2013 11:22 | Tomas Urban | Note Added: 0011808 |
21-11-2013 13:27 | Gyorgy Rethy | Note Added: 0011813 |
21-11-2013 13:27 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
21-11-2013 13:27 | Gyorgy Rethy | Status | new => assigned
21-11-2013 13:27 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06)
26-11-2013 10:16 | Jacob Wieland - Spirent | Note Added: 0011831 |
26-11-2013 14:31 | Jacob Wieland - Spirent | File Added: CR6647.doc |
26-11-2013 14:32 | Jacob Wieland - Spirent | Note Added: 0011834 |
26-11-2013 14:32 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
26-11-2013 14:32 | Jacob Wieland - Spirent | Status | assigned => confirmed
08-04-2014 16:51 | Gyorgy Rethy | Target Version | v4.6.1 (published 2014-06) => v4.7.1 (published 2015-06)
06-10-2014 15:00 | Gyorgy Rethy | Priority | normal => high
08-10-2014 07:55 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
08-10-2014 13:51 | Jens Grabowski | Note Added: 0012282 |
08-10-2014 13:51 | Jens Grabowski | Status | confirmed => resolved
08-10-2014 13:51 | Jens Grabowski | Resolution | open => fixed
08-10-2014 13:51 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
05-01-2015 17:41 | Gyorgy Rethy | Note Added: 0012625 |
05-01-2015 17:41 | Gyorgy Rethy | Status | resolved => closed
05-01-2015 17:41 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)

Notes

(0011808)
Tomas Urban
18-10-2013 11:22

I am afraid that my original post not entirely correct. 6.2.8 doesn't directly indicate that using an default reference related to a different component leads to an error, but that such a reference "has no meaning". This expression is rather unfortunate, because it is somehow ambiguous.
However, the most typical use of this reference, i.e. the deactivate operation will cause an error according to the rules in 20.5.3:
- A test component cannot deactivate a default in another test component.
- Calling a deactivate operation with an undefined default reference ... shall cause a runtime error.
Assignment and parameter passing would probably still work, because it doesn't analyze the content.
There might be problems with a log statement, because it is a question how to interpret this value with "no meaning" and comparing values with "no meaning" might be somehow difficult too.
Thus I believe there's still a good justification for the original CR and it could be also considered, whether the rule from the chapter 6.2.8 (Default references have meaning only within the test component instances they are activated, i.e. a default reference assigned to a default variable in test component instance "a1" of type "A" has no meaning in test component instance
"a2" of type "A".) shouldn't be dropped, because if the proposal is implemented there won't be any way of passing a default to a different component.

(0011813)
Gyorgy Rethy
21-11-2013 13:27

I agree with Thomas's proposal. Jacob, pls. look at it; I also propose to separate the two bullet items of restriction b) (on the runs on clause and on formal parameters) into two distinct restrictions.

(0011831)
Jacob Wieland - Spirent
26-11-2013 10:16

Off the top of my head, I can think of a scenario where using a default value from another component would not be an error: passing that value back to the original component in a message which then that component can use to deactivate the default. Anyway, forbidding this now would be backward incompatible, so I don't see the point.

(0011834)
Jacob Wieland - Spirent
26-11-2013 14:32

I've added a proposal to the effect of the wishes of the reporter. Please review.

(0012282)
Jens Grabowski
08-10-2014 13:51

Proposal is fine with me.

(0012625)
Gyorgy Rethy
05-01-2015 17:41

Added to draft V4.6.3