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

ID | Project | Category | View Status | Date Submitted | Last Update
0007991 | Part 01: TTCN-3 Core Language | Technical | public | 03-11-2020 08:37 | 16-12-2020 17:27

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) | 20.4
Source (company - Author) | Elvior OÜ

Summary | 0007991: @nodefault for interleave
Description | The @nodefault modifier should be avaliable in the interleave statement as well.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR_7991.docx (302,815) 08-12-2020 20:44 http://oldforge.etsi.org/mantis/file_download.php?file_id=3976&type=bug CR_7991_v2.docx (302,802) 09-12-2020 09:01 http://oldforge.etsi.org/mantis/file_download.php?file_id=3979&type=bug

Issue History
Date Modified | Username | Field | Change
03-11-2020 08:37 | Tomas Urban | New Issue |
07-12-2020 12:03 | Jens Grabowski | Assigned To | => KristÃ³f Szabados
07-12-2020 12:03 | Jens Grabowski | Status | new => assigned
08-12-2020 20:44 | KristÃ³f Szabados | File Added: CR_7991.docx |
08-12-2020 20:46 | KristÃ³f Szabados | Note Added: 0015815 |
08-12-2020 20:46 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
08-12-2020 20:46 | KristÃ³f Szabados | Status | assigned => confirmed
09-12-2020 07:38 | Tomas Urban | Note Added: 0015817 |
09-12-2020 07:38 | Tomas Urban | Assigned To | Tomas Urban => KristÃ³f Szabados
09-12-2020 07:38 | Tomas Urban | Status | confirmed => assigned
09-12-2020 09:01 | KristÃ³f Szabados | File Added: CR_7991_v2.docx |
09-12-2020 09:01 | KristÃ³f Szabados | Note Added: 0015821 |
09-12-2020 09:01 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Tomas Urban
09-12-2020 09:01 | KristÃ³f Szabados | Status | assigned => confirmed
09-12-2020 09:05 | Tomas Urban | Note Added: 0015822 |
09-12-2020 09:05 | Tomas Urban | Status | confirmed => resolved
09-12-2020 09:05 | Tomas Urban | Resolution | open => fixed
09-12-2020 09:05 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
16-12-2020 17:27 | Gyorgy Rethy | Note Added: 0015874 |
16-12-2020 17:27 | Gyorgy Rethy | Status | resolved => closed
16-12-2020 17:27 | Gyorgy Rethy | Product Version | => 4.12.1 (published 2020-05)
16-12-2020 17:27 | Gyorgy Rethy | Fixed in Version | => 4.13.1 (ongoing)
16-12-2020 17:27 | Gyorgy Rethy | Target Version | => 4.13.1 (ongoing)

Notes

(0015815)
KristÃ³f Szabados
08-12-2020 20:46

I have added the first proposal, please check. Please note, that the BNF was not updated for the alt statement with the @nodefault modifier. I have updated it, but there might be other locations with such issues too.

(0015817)
Tomas Urban
09-12-2020 07:38

I am afraid that some contradiction in the proposal. The proposed rule says that "If the interleave statement contains the @nodefault modifier, all active default alternatives are ignored for the execution of this interleave statement." In my understanding it virtually switches off defaults inside the transformed alt block, thus behaves as if every nested alt statement had the @nodefault modifier.
However, the note says that only the outermost alt is generated with the @nodefault modifier.
In my opinion, the rule is correct and the note isn't, because as a user, I would expect that by switching off the default handling I make sure I get all the messages I included in the interleave without any single of them being replaced by a random default.
We should also consider what happens when we combine present/missing @nodefault modifier on the interleave level with a present/missing @nodefault modifier of an alt statement (including implicit one such as a stanalone receive) inside it. For simplicity, I would prefer that all transformed alt statements would have the same modifier as the interleave statement.
Thumbs up for detecting the issue with the alt statement BNF rule.

(0015821)
KristÃ³f Szabados
09-12-2020 09:01

Fixed the note. Please check it.

(0015822)
Tomas Urban
09-12-2020 09:05

The proposal can be added to the next version of the core language specification.

(0015874)
Gyorgy Rethy
16-12-2020 17:27

Implemented in draft 4.12.2