Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006691Part 01: TTCN-3 Core LanguageClarificationpublic21-02-2014 07:4106-01-2015 19:15
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Summary0006691: Port visibility in compile time in connection operations
DescriptionWith 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.

TagsNo tags attached.
Clause Reference(s)21.1
Source (company - Author)Elvior
Attached Filesdocx file icon CR6691_update_proposal.docx [^] (25,754 bytes) 10-04-2014 13:49
docx file icon CR6691_v2.docx [^] (27,148 bytes) 07-10-2014 15:18
docx file icon CR6691_v3.docx [^] (21,601 bytes) 07-10-2014 15:29

- Relationships

-  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
Powered by Mantis Bugtracker