ETSI's Bug Tracker |
Anonymous | Login | Signup for local Mantis account | 03-05-2024 00:51 IST |
Main | My View | View Issues | Change Log | Roadmap | Monitor project |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0006691 | Part 01: TTCN-3 Core Language | Clarification | public | 21-02-2014 07:41 | 06-01-2015 19:15 | ||||
Reporter | Tomas Urban | ||||||||
Assigned To | Gyorgy Rethy | ||||||||
Priority | normal | Severity | minor | Reproducibility | N/A | ||||
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) | ||||||
Summary | 0006691: Port visibility in compile time in connection operations | ||||||||
Description | With the introduction of mtc and system clauses in 4.6.1, it is possible to achieve that all component references in connection operations are strongly typed. However, the current specification doesn't actually say that this strong typing influences port references used in communication operations in any way and it is not obvious whether such port references shall be resolved according to the strong typing rules in compilation time or in runtime using the real component instance. The same problem was present in earlier specifications too, but then it only concerned component variables and reference to self. Let's demonstrate it on the example: type port P message { inout integer; } type component C1 { port P p1; } type component C2 { port P p1, p2; } testcase TC runs on C1 system C1 { var C1 v_ptc := C2.create; // valid assignment: C2 is compatible in C1 // In the following statement, v_ptc:p2 is not visible according to strong // typing rules, but the real instance contains the port p2. Static check // made in compilation time should print an error, but runtime check would // succeed connect(self:p1, v_ptc:p2); } In strongly typed languages, static checks are typically made in these cases leading to compilation errors. In order to prevent it, it is necessary to use explicit casting. TTCN-3 doesn't have any casting concept, but it is possible to use alternative approaches, such as assignment to a temporary variable or typing on the function level using runs on, mtc and system clauses. For this reason, I suggest to introduce strong typing rules for situations when the component type is known by adding the following rule to the section 21.1.1 and 21.1.2: If the type of the component referenced in a connection operation is known (either when the component reference is a variable or value returned from a function or the type is defined the runs on, mtc or system clause of the calling function), the referenced port declaration shall be present in this component type. It would be also beneficial to add an example to demonstrate this rule. For test suites with untyped mtc and system, everything would remain the same, because only runtime resolution is possible in these cases. If the proposed strong typing rule is not acceptable, the core language specification should still say that the port reference are related to the actual instance. Otherwise there will be different interpretations by tool vendors leading to real test suites portability issues. | ||||||||
Tags | No tags attached. | ||||||||
Clause Reference(s) | 21.1 | ||||||||
Source (company - Author) | Elvior | ||||||||
Attached Files | CR6691_update_proposal.docx [^] (25,754 bytes) 10-04-2014 13:49 CR6691_v2.docx [^] (27,148 bytes) 07-10-2014 15:18 CR6691_v3.docx [^] (21,601 bytes) 07-10-2014 15:29 | ||||||||
Notes | |
(0011944) Gyorgy Rethy (reporter) 07-04-2014 15:43 |
stf478, 2014-04-07: type-restriction based limitation applies, i.e. the above connect example shall produce an error. Standard has to be checked, if it is unambiguous from the text and amend if needed. |
(0012006) Axel Rennoch (developer) 10-04-2014 13:50 |
Problem: assignments to component instance may cause non-visible ports within components Approach: existing port identifiers that are not visible could not be detected at compile time and should not be used in connection statements |
(0012659) Gyorgy Rethy (reporter) 06-01-2015 19:15 |
Added to draft V4.6.3 |
Issue History | |||
Date Modified | Username | Field | Change |
21-02-2014 07:41 | Tomas Urban | New Issue | |
07-04-2014 15:43 | Gyorgy Rethy | Note Added: 0011944 | |
07-04-2014 15:51 | Gyorgy Rethy | Assigned To | => Axel Rennoch |
07-04-2014 15:51 | Gyorgy Rethy | Status | new => assigned |
08-04-2014 17:01 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06) |
10-04-2014 13:49 | Axel Rennoch | File Added: CR6691_update_proposal.docx | |
10-04-2014 13:49 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy |
10-04-2014 13:50 | Axel Rennoch | Note Added: 0012006 | |
10-04-2014 13:50 | Axel Rennoch | Status | assigned => confirmed |
06-10-2014 15:29 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski |
07-10-2014 15:18 | Tomas Urban | File Added: CR6691_v2.docx | |
07-10-2014 15:29 | Jens Grabowski | File Added: CR6691_v3.docx | |
07-10-2014 15:29 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
07-10-2014 15:29 | Jens Grabowski | Status | confirmed => assigned |
07-10-2014 15:29 | Jens Grabowski | Status | assigned => resolved |
07-10-2014 15:29 | Jens Grabowski | Resolution | open => fixed |
06-01-2015 19:15 | Gyorgy Rethy | Note Added: 0012659 | |
06-01-2015 19:15 | Gyorgy Rethy | Status | resolved => closed |
06-01-2015 19:15 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06) |
MantisBT 1.2.14 [^] Copyright © 2000 - 2024 MantisBT Team |