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

ID | Project | Category | View Status | Date Submitted | Last Update
0007195 | Part 01: TTCN-3 Core Language | New Feature | public | 09-10-2015 15:27 | 12-12-2016 20:28

Reporter | Jacob Wieland - Spirent |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.9.1 (published 2017-05) | Fixed in Version | v4.9.1 (published 2017-05) |
Clause Reference(s) | 20.4
Source (company - Author) | Testing Technologies - Jacob Wieland

Summary | 0007195: interleave is much too restricted

Description

The restriction a) of the Interleave Statement unnecessarily disallows far too much.
Unproblematic are:
- activate/deactivate
- stop (same as break+stop)
- loops/conditionals containing no (potentially) blocking statements
- direct invocation of altsteps (same as alt statements with altsteps)
- return (same as break + return)
- goto outside the interleave (same as break + goto)
If the restrictions were to be relaxed to disallow only repeat, function calls containing blocking statements and loops/if-statements containing blocking statements, the mapping to alt-statements would still possible with the expected semantics.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR-7195.docx (21,380) 28-12-2015 11:27 http://oldforge.etsi.org/mantis/file_download.php?file_id=3397&type=bug

Issue History
Date Modified | Username | Field | Change
09-10-2015 15:27 | Jacob Wieland - Spirent | New Issue |
03-11-2015 16:07 | Gyorgy Rethy | Note Added: 0013478 |
03-11-2015 16:07 | Gyorgy Rethy | Assigned To | => Jens Grabowski
03-11-2015 16:07 | Gyorgy Rethy | Status | new => assigned
04-11-2015 13:58 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
04-11-2015 13:59 | Gyorgy Rethy | Target Version | => v4.8.1 (published 2016-07)
05-11-2015 15:28 | Jens Grabowski | Note Added: 0013505 |
05-11-2015 15:33 | Jens Grabowski | Note Added: 0013506 |
05-11-2015 16:04 | Jens Grabowski | Note Added: 0013510 |
05-11-2015 16:37 | Jens Grabowski | Note Added: 0013511 |
05-11-2015 19:13 | Jacob Wieland - Spirent | Note Added: 0013513 |
06-11-2015 11:12 | Gyorgy Rethy | Note Added: 0013516 |
28-12-2015 11:27 | Jens Grabowski | File Added: CR-7195.docx |
28-12-2015 11:29 | Jens Grabowski | Note Added: 0013650 |
28-12-2015 11:29 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
28-12-2015 11:29 | Jens Grabowski | Status | assigned => confirmed
18-07-2016 14:51 | Jens Grabowski | Assigned To | Gyorgy Rethy => KristÃ³f Szabados
18-07-2016 14:51 | Jens Grabowski | Status | confirmed => assigned
18-07-2016 14:51 | Jens Grabowski | Status | assigned => confirmed
17-08-2016 10:48 | Jacob Wieland - Spirent | Target Version | v4.8.1 (published 2016-07) => v4.9.1 (published 2017-05)
18-08-2016 08:24 | KristÃ³f Szabados | Note Added: 0014146 |
18-08-2016 08:24 | KristÃ³f Szabados | Status | confirmed => resolved
18-08-2016 08:24 | KristÃ³f Szabados | Fixed in Version | => v4.9.1 (published 2017-05)
18-08-2016 08:24 | KristÃ³f Szabados | Resolution | open => fixed
18-08-2016 08:24 | KristÃ³f Szabados | Assigned To | KristÃ³f Szabados => Gyorgy Rethy
12-12-2016 20:28 | Gyorgy Rethy | Note Added: 0014399 |
12-12-2016 20:28 | Gyorgy Rethy | Status | resolved => closed

Notes

(0013478)
Gyorgy Rethy
03-11-2015 16:07

STF discussion: check that allowing which operation keeps interleave and the final semantics easy to understand and which one would make it difficult to understand the expected behaviour. We can allow the obvious and easy-to-use ones.

(0013505)
Jens Grabowski
05-11-2015 15:28

Note 1: - stop (same as break+stop) - return (same as break + return) - goto outside the interleave (same as break + goto) can be allowed, Jacob already provided the corresponding semantics.

(0013506)
Jens Grabowski
05-11-2015 15:33

Note 2: - - loops/conditionals containing no (potentially) blocking statements If I interprete this correctly, such loops/conditionals are loops/conditionals within statement blocks embedded in interleave statements. I.e., such loops will always appear as a whole in the textual replacement semantics. If yes, it can be allowed.

(0013510)
Jens Grabowski
05-11-2015 16:04

Note 3: - activate/deactivate The textual expansion mechanism may easily provide a semantics for this, but the effects are difficult to predict. The test outcome may become dependent on the order in which the ports are examined. But the idea of interleave is exactly the opposite, i.e., specifying reception sequences where the order in which the ports are examined plays no role.

(0013511)
Jens Grabowski
05-11-2015 16:37

Note 4a)
- direct invocation of altsteps (same as alt statements with altsteps)
First case (example):
interleave {
[] receive(M1){};
[] MyAltstep(){};
}
Shall this be allowed? What is the interpretation?
Interpretation 1: M1 and all top alternatives of MyAltstep are interleaved.
In this case the interpretation of MyAltstep becomes context dependent. If used in an alt construct, only one alternative is executed. If used in an interleave, all alternatives are interleaved executed.
I am against such context dependent interpretations!
Interpretation 2: The evaluation order in MyAltstep is kept but interleaved with the reception of M1.
If MyAltstep includeds nested alt statements and one alternative in MyAltstep is chosen first, M1 may be interleaved with the altstep internal alternatives. This may be difficult to understand.
In addition, Altsteps used within interleave must follow the same restrictions as interleave statements, i.e., special restrictions for altsteps used in certain places.
Interpretation 3: Not allowed.

(0013513)
Jacob Wieland - Spirent
05-11-2015 19:13

Actually, when I raised this issue I was not even thinking about your example, but about this one:
interleave {
[] p.receive(A); { MyAltstep(); ... }
[] ...
}
which is equivalent to
interleave {
[] p.receive(A); { alt{ [] MyAltstep(); {} } ... }
[] ...
}
which does not violate any restrictions at the moment, but has obviously the same problems as the example you have given.
In principle, I share your opinion that only the interpretation 2 would be acceptable (from 1 and 2), but it would require the same restrictions as for interleave to the invoked altsteps recursively. To achieve this, the mapping semantics would have to be changed to first unfold all altstep invocations (i.e they shall not be recursive) and then impose the interleave-to-alt-translation (if no violation of the other restrictions occurs in the unfolded interleave).
However, if that is the case, then the same restriction must hold for usage of altsteps also in alt statements in the statement blocks of the interleave branches! No such restriction is imposed at the moment on the statement blocks.
Thus, to be consistent either altstep instances must be allowed inside the whole interleave structure, stand-alone or not (with other interleave restrictions imposed on them) or they should be disallowed both inside alt statements and stand-alone.

(0013516)
Gyorgy Rethy
06-11-2015 11:12

STF discussion: cover Note 1 & 2 below by this CR and add a clarification that all altstep calles are forbidden (clarify direct call).

(0013650)
Jens Grabowski
28-12-2015 11:29

Resolution attached. I put it to confirmed and assign it directly to György as it implements the STF discussion.

(0014146)
KristÃ³f Szabados
18-08-2016 08:24

Implements STF decision, looks fine by me.

(0014399)
Gyorgy Rethy
12-12-2016 20:28

Added to draft V4.8.2