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

ID | Project | Category | View Status | Date Submitted | Last Update
0007925 | Part 01: TTCN-3 Core Language | Technical | public | 22-04-2020 08:08 | 16-12-2020 16:55

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.12.1 (published 2020-05) |
Target Version | 4.13.1 (ongoing) | Fixed in Version | 4.13.1 (ongoing) |
Clause Reference(s) | 15.3
Source (company - Author) | Elvior

Summary | 0007925: Non-abstract signature templates
Description | The restriction on non-abstract templates 15.3.d should apply to message templates only. In case of signature templates, the restriction shall say that either all in parameters or all out parameters (or both) shall be fully initialized if the template is not marked as abstract.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR7925-1.docx (182,874) 12-08-2020 08:57 http://oldforge.etsi.org/mantis/file_download.php?file_id=3917&type=bug CR7925-2.docx (183,621) 13-08-2020 11:21 http://oldforge.etsi.org/mantis/file_download.php?file_id=3934&type=bug

Issue History
Date Modified | Username | Field | Change
22-04-2020 08:08 | Tomas Urban | New Issue |
10-08-2020 10:35 | Jens Grabowski | Assigned To | => Tomas Urban
10-08-2020 10:35 | Jens Grabowski | Status | new => assigned
12-08-2020 08:52 | Tomas Urban | File Added: CR7925.docx |
12-08-2020 08:57 | Tomas Urban | File Deleted: CR7925.docx |
12-08-2020 08:57 | Tomas Urban | File Added: CR7925-1.docx |
12-08-2020 08:57 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
12-08-2020 08:57 | Tomas Urban | Note Added: 0015704 |
12-08-2020 09:28 | Tomas Urban | Status | assigned => confirmed
12-08-2020 14:56 | Jacob Wieland - Spirent | Note Added: 0015713 |
12-08-2020 14:56 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
12-08-2020 14:56 | Jacob Wieland - Spirent | Status | confirmed => assigned
13-08-2020 08:36 | Tomas Urban | File Added: CR7969-2.docx |
13-08-2020 08:46 | Tomas Urban | Note Added: 0015719 |
13-08-2020 08:46 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
13-08-2020 08:46 | Tomas Urban | Status | assigned => confirmed
13-08-2020 08:46 | Tomas Urban | Note Edited: 0015719 | bug_revision_view_page.php?bugnote_id=15719#r524
13-08-2020 10:10 | Jacob Wieland - Spirent | Note Added: 0015723 |
13-08-2020 10:10 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Tomas Urban
13-08-2020 10:10 | Jacob Wieland - Spirent | Status | confirmed => assigned
13-08-2020 11:21 | Tomas Urban | File Deleted: CR7969-2.docx |
13-08-2020 11:21 | Tomas Urban | File Added: CR7925-2.docx |
13-08-2020 11:21 | Tomas Urban | Note Added: 0015726 |
13-08-2020 11:22 | Tomas Urban | Assigned To | Tomas Urban => Jacob Wieland - Spirent
13-08-2020 11:22 | Tomas Urban | Status | assigned => confirmed
13-08-2020 13:33 | Jens Grabowski | Assigned To | Jacob Wieland - Spirent => KristÃ³f Szabados
13-08-2020 13:33 | Jens Grabowski | Status | confirmed => assigned
14-08-2020 09:56 | KristÃ³f Szabados | Note Added: 0015748 |
14-08-2020 09:56 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
07-10-2020 09:57 | Tomas Urban | Note Added: 0015764 |
07-10-2020 10:26 | Tomas Urban | Note Added: 0015771 |
07-10-2020 10:26 | Tomas Urban | Status | assigned => resolved
07-10-2020 10:26 | Tomas Urban | Resolution | open => fixed
07-10-2020 10:26 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
16-12-2020 16:55 | Gyorgy Rethy | Note Added: 0015870 |
16-12-2020 16:55 | Gyorgy Rethy | Status | resolved => closed
16-12-2020 16:55 | Gyorgy Rethy | Product Version | => 4.12.1 (published 2020-05)
16-12-2020 16:55 | Gyorgy Rethy | Fixed in Version | => 4.13.1 (ongoing)

Notes

(0015704)
Tomas Urban
12-08-2020 08:57

Resolution uploaded. Please check.

(0015713)
Jacob Wieland - Spirent
12-08-2020 14:56

I think the proposal is still problematic. A completely initialized reply template (out/inout initialized) which is not completely initialized as a call template should not be used in call/getcall and vice versa. Thus, this should probably be clarified that for certain operations, the template need to be completely initialized in a specific way (and not one of two possible ways).

(0015719)
Tomas Urban
13-08-2020 08:46

I added related rules to these cases (in + inout -> only call and getcall; out + inout -> only reply and getreply). That should hopefully resolve the issue and allow compilers to detect some errors while still being backwards compatible.

(0015723)
Jacob Wieland - Spirent
13-08-2020 10:10

unfortunately, the last proposal is one for a different CR, please replace with correct one.

(0015726)
Tomas Urban
13-08-2020 11:21

Please check now.

(0015748)
KristÃ³f Szabados
14-08-2020 09:56

Maybe the current text is a bit too restrictive?
"
• All procedure parameters are fully initialized.
• All in and inout procedure parameters are completely initialized and all out procedure parameters are either unitialized or marked as not relevant using the NotUsedSymbol. Templates declared this way are safe to be used in call and getcall operations, but they shall not be used in reply and getreply operations.
"
What if my signature has 2 out parameters, I set one of it to a "normal" value and the other is left uninitialized/set to notusedsymbol ?
This should still be safe to be used in call and getcall operations, since the values of the out parameters are simply ignored.
Maybe it is not the most performant code to set an ignored parameter to som value ... but should not cause harm.
The same argument can also be said with in parameters and reply operations. They will be ignored .. that is not really efficient, but also not a reason for error either.

(0015764)
Tomas Urban
07-10-2020 09:57

What is the use case for creating such a non-abstract template? I cannot figure out any other than further extension in which case the template should be marked as abstract.
On many occasions you emphasized that language design should encourage good coding practices. Writing inefficient code (though a safe one) is definitely not a good coding practice.
Partially defined templates cause real problems, because they are usally discovered late in production testing. The common way how they get into the code is when new elements are added to types (or parameters in case of signatures) and the related templates are not updated.
Consider this:
signature S(in integer p1, in integer p2);
template S mw_sign1 := { p1:= 2 }
According to my proposal, this should produce an error. However, if we apply the rules you suggest, this is a completey fine template for reply and getreply operations. In my opinion, it would be quite misleading.

(0015771)
Tomas Urban
07-10-2020 10:26

After TTF discussion it was decided to go on with the more restrictive option.

(0015870)
Gyorgy Rethy
16-12-2020 16:55

Implemented in draft 4.12.2