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

ID | Project | Category | View Status | Date Submitted | Last Update
0007884 | Part 01: TTCN-3 Core Language | Technical | public | 21-11-2019 10:58 | 28-12-2019 15:55

Reporter | KristÃ³f Szabados |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version |  | Fixed in Version | 4.12.1 (published 2020-05) |
Clause Reference(s) | many
Source (company - Author) | TestCom ou

Summary | 0007884: the current standard is not really specific on how records with port types as field work

Description

In previous versions of the TTCN-3 core standard it was not allowed to have a record field with component/port/timer as its type.
This restriction is no longer present in the current latest version.
But this leaves some situations in the current version ambiguous.
For example:
- There is no restriction on sending values of structured type that have a port as a field. But there is also no description on what sending a port through a network is supposed to mean.
- In the usual case when a record variable is assigned a value of a second record variable, operations on the fields of the second variable are not expected to change fields of the first variable. But with ports this either has to change both variables (in case the port typed field is a reference), or there should be some description on copiing port.
- The life of ports should also be clarified. As long as they were component members it was clear that they are created/initialized with the component, and die with the component ... but creating copies inside records and sending them around, might lead to confusion if not clarified.
- There does not seem to be any restriction on using record type with port fields as in/out/inout message type of on a port ... but as creating templates of such type is not allowed the "?" in "someport.receive(?)..." becomes erroneous.
etc...

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7884-1.docx (218,074) 16-12-2019 13:52 http://oldforge.etsi.org/mantis/file_download.php?file_id=3874&type=bug CR7884-2.docx (255,004) 17-12-2019 10:04 http://oldforge.etsi.org/mantis/file_download.php?file_id=3881&type=bug CR7884-3.docx (213,892) 17-12-2019 14:07 http://oldforge.etsi.org/mantis/file_download.php?file_id=3886&type=bug

Issue History
Date Modified | Username | Field | Change
21-11-2019 10:58 | KristÃ³f Szabados | New Issue |
21-11-2019 11:08 | Jacob Wieland - Spirent | Note Added: 0015506 |
21-11-2019 11:57 | Jacob Wieland - Spirent | Note Added: 0015507 |
12-12-2019 12:53 | KristÃ³f Szabados | Note Added: 0015509 |
16-12-2019 09:02 | Jens Grabowski | Note Added: 0015512 |
16-12-2019 09:02 | Jens Grabowski | Assigned To | => Tomas Urban
16-12-2019 09:02 | Jens Grabowski | Status | new => assigned
16-12-2019 13:52 | Tomas Urban | File Added: CR7884-1.docx |
16-12-2019 13:53 | Tomas Urban | Note Added: 0015526 |
16-12-2019 13:53 | Tomas Urban | Assigned To | Tomas Urban => KristÃ³f Szabados
16-12-2019 13:53 | Tomas Urban | Status | assigned => confirmed
17-12-2019 08:46 | Jacob Wieland - Spirent | Note Added: 0015535 |
17-12-2019 08:47 | KristÃ³f Szabados | Note Added: 0015536 |
17-12-2019 08:47 | KristÃ³f Szabados | Status | confirmed => resolved
17-12-2019 08:47 | KristÃ³f Szabados | Fixed in Version | => 4.11.1 (published 2019-05)
17-12-2019 08:47 | KristÃ³f Szabados | Resolution | open => fixed
17-12-2019 08:47 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jens Grabowski
17-12-2019 08:54 | Jacob Wieland - Spirent | Assigned To | Jens Grabowski => Tomas Urban
17-12-2019 08:54 | Jacob Wieland - Spirent | Status | resolved => feedback
17-12-2019 08:54 | Jacob Wieland - Spirent | Resolution | fixed => reopened
17-12-2019 08:54 | Jacob Wieland - Spirent | Status | feedback => assigned
17-12-2019 10:04 | Tomas Urban | File Added: CR7884-2.docx |
17-12-2019 10:05 | Tomas Urban | Note Added: 0015541 |
17-12-2019 10:05 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
17-12-2019 10:05 | Tomas Urban | Status | assigned => confirmed
17-12-2019 14:06 | Jacob Wieland - Spirent | Status | confirmed => new
17-12-2019 14:07 | Jacob Wieland - Spirent | File Added: CR7884-3.docx |
17-12-2019 14:07 | Jacob Wieland - Spirent | Note Added: 0015558 |
17-12-2019 14:07 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
17-12-2019 14:07 | Jacob Wieland - Spirent | Status | new => confirmed
18-12-2019 07:17 | KristÃ³f Szabados | Note Added: 0015564 |
18-12-2019 07:17 | KristÃ³f Szabados | Status | confirmed => resolved
18-12-2019 07:17 | KristÃ³f Szabados | Resolution | reopened => fixed
18-12-2019 07:17 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
28-12-2019 15:55 | Gyorgy Rethy | Note Added: 0015590 |
28-12-2019 15:55 | Gyorgy Rethy | Status | resolved => closed
28-12-2019 15:55 | Gyorgy Rethy | Fixed in Version | 4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)

Notes

(0015506)
Jacob Wieland - Spirent
21-11-2019 11:08

As far as I know only data types can be sent/received and data types cannot contain port/component/object/default references.

(0015507)
Jacob Wieland - Spirent
21-11-2019 11:57

Hmm, somehow I can't find that definition or restrictions related to it anymore in the standard. In my recollection, a data type was a type that didn't contain reference types and only data types can be sent/received or used as parameters to functions started on other components. We should (re)introduce those definitions/restrictions again.

(0015509)
KristÃ³f Szabados
12-12-2019 12:53

Maybe the restrictions were removed by accident? For me it would sound ok if we could reintroduce them.

(0015512)
Jens Grabowski
16-12-2019 09:02

STF discussion: The restriction shall be reintroduced.

(0015526)
Tomas Urban
16-12-2019 13:53

Resolution uploaded, please check.

(0015535)
Jacob Wieland - Spirent
17-12-2019 08:46

I am not convinced that this is a good solution for several reasons:
- You repeat the same list over and over and this will have to be amended for class types in the OO package.
- the only exception are component references for the parameters of start-functions (how is it for component-call?)
It would be easier to have two kinds of definitions: data-type (all except these reference types) and component data types that also allow components (these could also be allowed to be sent via inter-component communication). Then, we would only have to amend these two definitions in the OO package.

(0015536)
KristÃ³f Szabados
17-12-2019 08:47

Looks fine for me, can be included to the standard.

(0015541)
Tomas Urban
17-12-2019 10:05

Data types and component data types added to the CR. Please review.

(0015558)
Jacob Wieland - Spirent
17-12-2019 14:07

simplified the recursive definitions and removed components from parameters of testcases

(0015564)
KristÃ³f Szabados
18-12-2019 07:17

Looks good to me. Can be included in the standard.

(0015590)
Gyorgy Rethy
28-12-2019 15:55

Included in final draft V4.11.2