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

ID | Project | Category | View Status | Date Submitted | Last Update
0007491 | Part 01: TTCN-3 Core Language | Clarification | public | 16-08-2016 09:08 | 09-07-2017 12:12

Reporter | KristÃ³f Szabados |
Assigned To | KristÃ³f Szabados |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | no change required |
Platform |  | OS |  | OS Version |
Product Version | v4.8.1 (published 2016-07) |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 6.2.6
Source (company - Author) | L. M. Ericsson

Summary | 0007491: confusing/incorrect texts related to anytype behaviour

Description

Recently the anytype type became global.
But the text describing it was not changed in every place, or leaves room for interpretation.
Anytype is global here:". the anytype shall comprise all the known data types but not the port, component, and default types"
Here it is local: "The anytype is defined locally for each module"
This just makes no sense in this context: "The address type shall be included if it has been explicitly defined within that module"

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7491_proposal_v1.docx (155,422) 16-08-2016 09:57 http://oldforge.etsi.org/mantis/file_download.php?file_id=3455&type=bug

Issue History
Date Modified | Username | Field | Change
16-08-2016 09:08 | KristÃ³f Szabados | New Issue |
16-08-2016 09:57 | KristÃ³f Szabados | File Added: CR7491_proposal_v1.docx |
16-08-2016 11:47 | Jens Grabowski | Assigned To | => Axel Rennoch
16-08-2016 11:47 | Jens Grabowski | Status | new => assigned
16-08-2016 13:35 | Axel Rennoch | Note Added: 0014108 |
16-08-2016 13:35 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
16-08-2016 13:35 | Axel Rennoch | Status | assigned => confirmed
17-08-2016 11:39 | Jacob Wieland - Spirent | Target Version | => v4.9.1 (published 2017-05)
13-12-2016 11:54 | Gyorgy Rethy | Note Added: 0014405 |
13-12-2016 11:54 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
13-12-2016 11:54 | Gyorgy Rethy | Status | confirmed => assigned
13-12-2016 11:54 | Gyorgy Rethy | Fixed in Version | => v4.10.1 (published 2018-05)
13-12-2016 11:58 | Gyorgy Rethy | Note Edited: 0014405 | bug_revision_view_page.php?bugnote_id=14405#r346
24-12-2016 14:57 | Jens Grabowski | Target Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
09-07-2017 12:12 | KristÃ³f Szabados | Note Added: 0014728 |
09-07-2017 12:12 | KristÃ³f Szabados | Status | assigned => closed
09-07-2017 12:12 | KristÃ³f Szabados | Resolution | open => no change required

Notes

(0014108)
Axel Rennoch
16-08-2016 13:35

The proposed text looks correct and the CR may be closed.

(0014405)
Gyorgy Rethy
13-12-2016 11:54 (edited on: 13-12-2016 11:58)

Currently, anytype is not defined to be a global type and there is no remark in the CR that the STF has decided to change this. If implementing, this CR would re-define the anytype, thus it is not implemented in the draft for the next version V4.9.1.
The current definition is:
In clause 6.2.6 The anytype:
"The special type anytype is defined as a shorthand for the union of all known data types and the address type in a TTCN 3 module. The definition of the term known types is given in clause 3.1, i.e. the anytype shall comprise all the known data types but not the port, component, and default types. The address type shall be included if it has been explicitly defined within that module."
In clause 3.1:
"known types: set of all TTCN 3 predefined types, types defined in a TTCN 3 module and types imported into that module from other TTCN 3 modules or from non-TTCN 3 modules."
Therefore anytype contains only the
- locally defined data types
- locally defined address type
- imported (by an explicit import statement) data types
Introductory text in clause 6.0 is corrected. Please check if any further correction is needed or the CR can be closed.

(0014728)
KristÃ³f Szabados
09-07-2017 12:12

was a misunderstanding on my side. The text is correct.