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

ID | Project | Category | View Status | Date Submitted | Last Update
0007883 | Part 01: TTCN-3 Core Language | New Feature | public | 15-10-2019 09:32 | 28-12-2019 12:54

Reporter | Tomas Urban |
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) | 15.0
Source (company - Author) | Elvior

Summary | 0007883: Fully initialized templates

Description

The current standard requires templates to be at least partially initialized:
15.0.d The expression or template body initializing a template shall evaluate to a value or a template that is at least partially initialized or to a matching mechanism.
This is useful in cases when some templates are used as abstract, containing just some basic values and the missing values are added in templates derived from them.
However, TTCN-3 language doesn't contain any mechanism that would allow the user to distinguish between abstract templates containing partially initialized values and fully initialized ones which could be safely used in communication operations.
Proposal:
Add a specific modifier that would require a static template to be fully initialized, e.g.
template @concrete MyType mw_msg ....
Since most templates are actually defined as fully initialized, more logical would be to mark the abstract ones:
template @abstract MyType mw_msgBase ....
However, this approach would create a change that is not backwards compatible.
It should be also explained in detail whether restricted templates can or may not be partially initialized.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7883-1.docx (221,192) 17-12-2019 08:54 http://oldforge.etsi.org/mantis/file_download.php?file_id=3879&type=bug

Issue History
Date Modified | Username | Field | Change
15-10-2019 09:32 | Tomas Urban | New Issue |
22-10-2019 07:53 | KristÃ³f Szabados | Note Added: 0015505 |
16-12-2019 09:21 | Jens Grabowski | Note Added: 0015513 |
16-12-2019 09:21 | Jens Grabowski | Assigned To | => Tomas Urban
16-12-2019 09:21 | Jens Grabowski | Status | new => assigned
17-12-2019 08:54 | Tomas Urban | File Added: CR7883-1.docx |
17-12-2019 08:55 | Tomas Urban | Note Added: 0015537 |
17-12-2019 08:55 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
17-12-2019 08:55 | Tomas Urban | Status | assigned => confirmed
17-12-2019 14:08 | Jacob Wieland - Spirent | Note Added: 0015559 |
17-12-2019 14:08 | Jacob Wieland - Spirent | Status | confirmed => resolved
17-12-2019 14:08 | Jacob Wieland - Spirent | Fixed in Version | => 4.11.1 (published 2019-05)
17-12-2019 14:08 | Jacob Wieland - Spirent | Resolution | open => fixed
17-12-2019 14:08 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
28-12-2019 12:54 | Gyorgy Rethy | Assigned To | Jens Grabowski => Gyorgy Rethy
28-12-2019 12:54 | Gyorgy Rethy | Status | resolved => assigned
28-12-2019 12:54 | Gyorgy Rethy | Note Added: 0015587 |
28-12-2019 12:54 | Gyorgy Rethy | Status | assigned => closed
28-12-2019 12:54 | Gyorgy Rethy | Fixed in Version | 4.11.1 (published 2019-05) => 4.12.1 (published 2020-05)

Notes

(0015505)
KristÃ³f Szabados
22-10-2019 07:53

If I remember correctly the current template restrictions can be used to check if a template can be safely sent on the network (value).
This might also be a tooling issue.
For example we have a code quality check for partially initialized items. So that users can pay special attention when working with them (+ creation and maintenance).
This way does not have any runtime performance overhead, since it is done on the code statically.

(0015513)
Jens Grabowski
16-12-2019 09:21

STF discussion: The introduction of "@abstract" as optional modifier is reasonable. The usage of partially initialized templates without "@abstract" should be deprecated in the future (put a warning into the standard).

(0015537)
Tomas Urban
17-12-2019 08:55

Resolution uploaded, please review.

(0015559)
Jacob Wieland - Spirent
17-12-2019 14:08

proposal is fine

(0015587)
Gyorgy Rethy
28-12-2019 12:54

Implemented in final draft 4.11.2.