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

ID | Project | Category | View Status | Date Submitted | Last Update
0007689 | Part 01: TTCN-3 Core Language | Technical | public | 27-06-2017 12:53 | 30-12-2017 19:51

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 | v4.9.1 (published 2017-05) |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 20.4
Source (company - Author) | Elvior

Summary | 0007689: Unconditional goto in interleave

Description

What exactly does the term unconditional goto (used in 20.4. restriction d) mean? The term is not precisely specified and might be interpreted in different ways. My interpretation is that goto cannot occur inside if-else, select-case, for and while. However, I do not understand the reason why this restriction is used when other similar jumps (break, return) can be "conditional".
I would prefer to remove the "unconditional" word completely. If that is not possible, the term should be precisely specified.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR-7689-170725.docx (65,693) 25-07-2017 08:51 http://oldforge.etsi.org/mantis/file_download.php?file_id=3650&type=bug

Issue History
Date Modified | Username | Field | Change
27-06-2017 12:53 | Tomas Urban | New Issue |
28-06-2017 09:09 | Jacob Wieland - Spirent | Note Added: 0014722 |
28-06-2017 09:10 | Jacob Wieland - Spirent | Note Added: 0014723 |
28-06-2017 09:50 | Tomas Urban | Note Added: 0014724 |
28-06-2017 10:20 | Jacob Wieland - Spirent | Note Added: 0014725 |
28-06-2017 10:21 | Jacob Wieland - Spirent | Note Edited: 0014725 | bug_revision_view_page.php?bugnote_id=14725#r425
28-06-2017 10:22 | Jacob Wieland - Spirent | Note Edited: 0014725 | bug_revision_view_page.php?bugnote_id=14725#r426
24-07-2017 14:18 | Jens Grabowski | Assigned To | => Jens Grabowski
24-07-2017 14:18 | Jens Grabowski | Status | new => assigned
25-07-2017 08:48 | Jens Grabowski | Note Added: 0014746 |
25-07-2017 08:51 | Jens Grabowski | File Added: CR-7689-170725.docx |
25-07-2017 08:52 | Jens Grabowski | Note Added: 0014748 |
25-07-2017 08:52 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
25-07-2017 08:52 | Jens Grabowski | Status | assigned => confirmed
25-07-2017 13:05 | Tomas Urban | Note Added: 0014751 |
25-07-2017 13:05 | Tomas Urban | Status | confirmed => resolved
25-07-2017 13:05 | Tomas Urban | Fixed in Version | => v4.10.1 (published 2018-05)
25-07-2017 13:05 | Tomas Urban | Resolution | open => fixed
25-07-2017 13:05 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
30-12-2017 19:51 | Gyorgy Rethy | Note Added: 0014968 |
30-12-2017 19:51 | Gyorgy Rethy | Status | resolved => closed
30-12-2017 19:51 | Gyorgy Rethy | Target Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)

Notes

(0014722)
Jacob Wieland - Spirent
28-06-2017 09:09

I think the whole idea of these restrictions was that there should be a linear path from the start of a block to the next reception statement to still allow the unfolding of the interleave to an alt-statement.
If-statements that include goto statements don't fit into that. In my opinion, goto statements that do not jump out of the interleave also don't really fit into that.
Additionally, if statements are not treated by this clause, though similar constructs are allowed if they don't contain reception statements.
const boolean E := C; while (E) { S1; break } while (not E) { S2; break; }
is equlivalent to
if (C) { S1 } else { S2 }
So, allowing if-statements that contain no reception statements should also be considered.

(0014723)
Jacob Wieland - Spirent
28-06-2017 09:10

you could say that goto statements should only be allowed if they don't jump over any reception statement.

(0014724)
Tomas Urban
28-06-2017 09:50

At the moment, if statements are implicitly allowed (there's no restriction saying that they cannot be used inside interleave statements).

(0014725)
Jacob Wieland - Spirent
28-06-2017 10:20 (edited on: 28-06-2017 10:22)

ah, yes, true, they don't even break the to-alt-mapping if they contain reception statements

(0014746)
Jens Grabowski
25-07-2017 08:48

The term "unconditional goto" is not used, the term "unconditional jump" only describes what a goto is. However, the term "unconditional" is only used in this section and we can savely remove it. See attached resolution.

(0014748)
Jens Grabowski
25-07-2017 08:52

If, ok, please assignt to György as resolved.

(0014751)
Tomas Urban
25-07-2017 13:05

The proposed resolution fixes the issue.

(0014968)
Gyorgy Rethy
30-12-2017 19:51

Added to draft V4.9.2