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

ID | Project | Category | View Status | Date Submitted | Last Update
0007874 | Part 01: TTCN-3 Core Language | Technical | public | 05-09-2019 10:34 | 15-12-2020 16:53

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 | 4.13.1 (ongoing) |
Target Version | 4.13.1 (ongoing) | Fixed in Version | 4.13.1 (ongoing) |
Clause Reference(s) | 15.8
Source (company - Author) | STF 572

Summary | 0007874: Reintroduce restriction on restricted modified templates

Description

CR 0007603 introduced compile-time checks on template restrictions. It should be considered to reintroduce the restriction 15.8.c which was removed from the standard in its TTCN-3:2013 version in order to comply with the "soft" interpretation of template restrictions.
This is the original text of the restriction (with minor modification: has to -> shall):
A restricted, modified template shall have the same or more restrictive restriction as the base template. A restricted parameter of a modified template shall have the same or a more restrictive restriction as the corresponding parameter of the base template. The allowed restrictions are listed in table 14.
Table 14: Restricting modified templates
Restriction in base template | Allowed restrictions in modified template
template | template, template(present), template(omit), template(value)
template(present) | template(present), template(value)
template(omit) | template(omit), template(value)
template(value) | template(value)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007603 | closed | Gyorgy Rethy | Delete note on template restriction passing table

Attached Files | CR_7874.docx (315,106) 18-12-2019 10:29 http://oldforge.etsi.org/mantis/file_download.php?file_id=3891&type=bug CR_7874-2.docx (349,256) 18-12-2019 12:35 http://oldforge.etsi.org/mantis/file_download.php?file_id=3894&type=bug CR_7874-3.docx (292,638) 18-12-2019 13:10 http://oldforge.etsi.org/mantis/file_download.php?file_id=3895&type=bug

Issue History
Date Modified | Username | Field | Change
05-09-2019 10:34 | Tomas Urban | New Issue |
05-09-2019 10:34 | Tomas Urban | Relationship added | related to 0007603
05-09-2019 12:27 | Tomas Urban | Note Added: 0015492 |
05-09-2019 14:27 | Tomas Urban | Note Added: 0015493 |
05-09-2019 15:17 | Jacob Wieland - Spirent | Note Added: 0015494 |
06-09-2019 08:08 | Tomas Urban | Note Edited: 0015493 | bug_revision_view_page.php?bugnote_id=15493#r503
06-09-2019 08:11 | Tomas Urban | Note Added: 0015495 |
06-09-2019 08:37 | Jacob Wieland - Spirent | Note Added: 0015496 |
06-09-2019 09:03 | Tomas Urban | Note Added: 0015497 |
06-09-2019 10:01 | Jacob Wieland - Spirent | Note Added: 0015498 |
06-09-2019 10:12 | Tomas Urban | Note Added: 0015499 |
16-12-2019 09:37 | Jens Grabowski | Note Added: 0015517 |
16-12-2019 09:37 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
16-12-2019 09:37 | Jens Grabowski | Status | new => assigned
16-12-2019 09:49 | Jens Grabowski | Note Added: 0015518 |
17-12-2019 12:23 | KristÃ³f Szabados | Note Added: 0015547 |
18-12-2019 10:29 | KristÃ³f Szabados | File Added: CR_7874.docx |
18-12-2019 10:30 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
18-12-2019 10:30 | KristÃ³f Szabados | Note Added: 0015576 |
18-12-2019 12:35 | Tomas Urban | File Added: CR_7874-2.docx |
18-12-2019 12:42 | Tomas Urban | Note Added: 0015582 |
18-12-2019 12:42 | Tomas Urban | Assigned To | Tomas Urban => KristÃ³f Szabados
18-12-2019 13:02 | KristÃ³f Szabados | Note Added: 0015583 |
18-12-2019 13:10 | KristÃ³f Szabados | File Added: CR_7874-3.docx |
18-12-2019 13:11 | KristÃ³f Szabados | Note Added: 0015584 |
18-12-2019 13:11 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Jacob Wieland - Spirent
24-01-2020 14:14 | Jacob Wieland - Spirent | Note Added: 0015608 |
24-01-2020 14:14 | Jacob Wieland - Spirent | Status | assigned => resolved
24-01-2020 14:14 | Jacob Wieland - Spirent | Fixed in Version | => 4.13.1 (ongoing)
24-01-2020 14:14 | Jacob Wieland - Spirent | Resolution | open => fixed
24-01-2020 14:14 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
24-01-2020 14:20 | Jacob Wieland - Spirent | Status | resolved => feedback
24-01-2020 14:20 | Jacob Wieland - Spirent | Resolution | fixed => reopened
24-01-2020 14:21 | Jacob Wieland - Spirent | Status | feedback => resolved
24-01-2020 14:21 | Jacob Wieland - Spirent | Resolution | reopened => fixed
24-01-2020 14:21 | Jacob Wieland - Spirent | Assigned To | Jens Grabowski => Gyorgy Rethy
15-12-2020 16:53 | Gyorgy Rethy | Note Added: 0015859 |
15-12-2020 16:53 | Gyorgy Rethy | Status | resolved => closed
15-12-2020 16:53 | Gyorgy Rethy | Product Version | => 4.13.1 (ongoing)
15-12-2020 16:53 | Gyorgy Rethy | Target Version | => 4.13.1 (ongoing)

Notes

(0015492)
Tomas Urban
05-09-2019 12:27

Actually, the first part of the restriction is problematic and in my opinion it should be vice versa, i.e. the modified template should have the same restriction or be less restrictive than the base template. That's because there are always some unmodified fields and if these fields do not comply with the restriction of the modified template, the content of the template would be invalid.

(0015493)
Tomas Urban
05-09-2019 14:27 (edited on: 06-09-2019 08:08)

Example demonstrating possible error when using stronger restriction: type record R { integer field1, integer field2 } ... { var template R vm_base := ?; var template(value) R vm_modified := modifies vm_base := { field1 := 1 } // after the assignment vm_modified.field1 contains ? which is not complient with the value restriction }

(0015494)
Jacob Wieland - Spirent
05-09-2019 15:17

This restriction should only apply when modifying template variables (since the content of the variable is unknown).
When modifying static templates, the restriction is not necessary. The only unknowns in there are formal parameters. In a value or omit template, the formal parameters are restricted to value/omit templates, as well, so it is always safe to modify a value/omit template with another value/omit-only modification because the result will be a value template.
If the base template was a present template, it cannot become a non-present template by modification with a body, so here again, the restriction cannot become worse.

(0015495)
Tomas Urban
06-09-2019 08:11

Since the original restriction 15.8.c is problematic, I would make a proposal for the new restrictions so that it is clear what we are discussing about:
c) A restricted, modified template shall have the same or less restrictive restriction as the base template. The allowed restrictions are listed in table 14.
Table 14: Restricting modified templates
Restriction of base template | Allowed restrictions of modified template
template | template
template(present) | template(present), template
template(omit) | template(omit), template
template(value) | template(value), template, template(present), template(omit)
d) A restricted parameter of a modified template shall have the same or a more restrictive restriction as the corresponding parameter of the base template. The allowed restrictions are listed in table 15.
Table 15: Changing restriction of formal parameters of modified templates
Parameter restriction in base template | Allowed parameter restrictions in modified template
template | template, template(present), template(omit), template(value)
template(present) | template(present), template(value)
template(omit) | template(omit), template(value)
template(value) | template(value)
Now some comments to Jacob's note:
1. Static templates declared in statement blocks might be dependent on variables. Even static templates from component blocks can have content that is not resolved during compilation (fields initialized by functions, dependent on module parameters, fuzzy templates).
2. I couldn't find a rule or restriction saying that formal parameters of a restricted template shall have the same or stronger restriction than the template. In my opinion, it is completely legal to define a template like this:
function f_testTemplate(template integer p_par) return integer {
if (isvalue(p_par)) { return valueof(p_par); }
else { return 0; }
}
template(value) R m_myMsg (template integer p_par) { // unrestricted template parameter p_par is not used in the template body directly thus it does not violate any rules on restricted templates
field1 := f_testTemplate(p_par),
field2 := 2019
}
// m_myMsg(?) would yield { field1 := 0, field2 := 2019 }
3. Example on problematic modification of a base template with a present restriction (currently allowed, leads to a runtime error):
var template(present) R vm_base := ?;
template(value) R vm_modified modifies vm_base := { field1 := 1 }
4. I don't agree that the rule should be restricted to variables. In TTCN-3:2018 we made a major change in the rules on restrictions saying that the content doesn't matter. E.g. this is not allowed any more, even though it would be perfectly legal in older versions of TTCN-3 and it wouldn't cause any error:
template R m_base2 := { field1 := 1, field2 := 2}
template(value) R m_valueTmpt := m_base2;
Why should a similar modification (see below) be legal just because it is static? The rules on restrictions should be universal and not consider the content in any case.
template(value) R m_modified2 modifies m_base2 := { field2 := 10 };

(0015496)
Jacob Wieland - Spirent
06-09-2019 08:37

The example you give in 3 is simply an erroneous usage that will yield a dynamic error, one that can already be warned about at compile-time (modifying a present template will not necessarily yield a value template).
There is no need for a backward-incompatible restriction, even for variables. There are myriad examples where modifying a present-template will yield a value-template. Such checks need only be done in special situations, so if the code uses the restrictions in a proper way, the executed won't even be inefficient.
This is pretty much on par with assigning a less restricted template (e.g. the result of a function) to a more restricted template variable. It's not forbidden (as far as I know) but it can fail, same as with type restrictions if the types just overlap.

(0015497)
Tomas Urban
06-09-2019 09:03

It is forbidden to assign a less restrictive template to a more restrictive template variable because of the restriction 15.8.b which applies to the example you provided (the less restrictive template returned by the function is on the right hand side of the assignment).
My argument for extension of the rule to modification is language consistency. The core lanugage specification should not allow something in one language statement and disallow it in another closely related one. If the restriction 15.8.b says that assignment of less restrictive template to a more restrictive one is not allowed regardless of the template content, a similar rule should be present for modification which is just a different kind of assignment.
As regards backwards incompatibility, the change made in 0007603 was also backwards incompatible and we resolved it by moving the old rules to the deprecated section. In reality it means that compilers issue warnings instead of errors in these case anyway (and generate runtime validation code for such assignments). The same principle could be used for modified templates as well.

(0015498)
Jacob Wieland - Spirent
06-09-2019 10:01

Please consider the following NOTE about this (from 15.8.)
NOTE: Template restrictions allow TTCN-3 tools to check more easily at compile time whether templates and
matching expressions are used correctly. Whether the checks are performed at compile time and invalid
code is rejected or whether the checks are performed at execution time and dynamic errors are raised, is
outside the scope of the present document.

(0015499)
Tomas Urban
06-09-2019 10:12

I am aware of this note and I think it is consistent with the proposed restrictions. According to the note, tools would still have a legal option to issue just a warning as it is the case with the restriction 15.8.b.

(0015517)
Jens Grabowski
16-12-2019 09:37

STF discussion: Kristof will prepare the discussion.

(0015518)
Jens Grabowski
16-12-2019 09:49

STF discussion: To be done: 1) Decision on restriction of modified templates. 2) Definition of "stricter" has to be added. This is related to 15.5 restriction b.2.

(0015547)
KristÃ³f Szabados
17-12-2019 12:23

STF discussion:
- the template result of modifies has the same restriveness as the base template.
- introduce the omit(template) and present(template) operators, that yield a template with omit and present restriction respectively.
- the parameters can be changed for stricter ones.
- add definition of strictness (as it is referenced).
- move to deprecated the current modifies behavior (where the result could be stricter)

(0015576)
KristÃ³f Szabados
18-12-2019 10:30

uploaded first draft, please review.

(0015582)
Tomas Urban
18-12-2019 12:42

New version of the resolution with three bigger changes:
- Template restriction operators changed to template operations and moved to the chapter 15 (also in the BNF)
- Modify the rule on restriction of modified templates so that the modified template can have less strict restriction and added a related table
- Added a description to the table 14
There are also some minor corrections in the text.
Please review

(0015583)
KristÃ³f Szabados
18-12-2019 13:02

Just a little notice: "A template with the omit restriction if the operand fulfils conditions of the omit template restriction as described in clause 15.8" Does not indicate any connection between the resulting template and the operand.

(0015584)
KristÃ³f Szabados
18-12-2019 13:11

fixed + typos, please review.

(0015608)
Jacob Wieland - Spirent
24-01-2020 14:14

Seems fine to me. Because this issue was assigned instead of confirmed, I missed it. Hope it can still be included.

(0015859)
Gyorgy Rethy
15-12-2020 16:53

Implemented in draft 4.12.2