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

ID | Project | Category | View Status | Date Submitted | Last Update
0005807 | Part 01: TTCN-3 Core Language | Technical | public | 24-11-2010 12:09 | 29-06-2011 14:33

Reporter | Wolfgang Seka |
Assigned To | Gyorgy Rethy |
Priority | low | Severity | major | Reproducibility | N/A
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.2 (interim 2011) | Fixed in Version |  |
Clause Reference(s) | Part 1 clause 20.4, part 4 and clause 7.5
Source (company - Author) | stf160 - Wolfgang

Summary | 0005807: Restrictions regarding interleave in section 20.4 are confusing and unecessary

Description

Issues:
- when it is not allowed to use 'repeat' in interleave statements it seems to be also not allowed to use 'repeat' in any default behaviour which is activated while 'interleave' is called.
This causes severe problems for implementation and maintenance when there is always a (standard) default acivated and there are messages which need to be ignored.
=> By strictly applying the current release of the TTCN-3 standard in fact 'interleve' is useless for stf160.
- Even though stf160 does not use it until now I don't see the justification for the restrictions listed in clause 20.4 of part 1 and clause 7.5 of part 4.
Since these restrictions are not necessary in the expanded representation with nested alt statments the restrictions shall be removed from the standards.
(please note that I've not checked the above statements to valid for all exceptions)
- There has been discussions on the TTCN-3 reflector about the expansion of 'interleave':
Inpendent of how compilers or tools implement 'interleave' it shall be clear that the behaviour of 'interleave' results in the same as the expansion with nested alt statements.
(and when this is the case, there shall be no other restrictions as for nested alt statements - see above).
If there are exceptions of these rules they shall be stated clearly.
- According to my understand 'break' results in leaving the whole interleave block whereas a 'break' in an inner alt statemente of nested alt statements will only cause leaving this alt statement.
When this interpretation is correct, it shall be mentioned that for 'break' there is an exception of the expansion rules (see above).

Steps To Reproduce |

Additional Information

Notes:
- In general when there are necessary restrictions but no tools checking whether they are fulfilled that is a fundamantal problem for projects like stf160 but also for tool compatibility:
We never know what will happen at run-time ...
- As a matter of experience 'normal' TTCN-3 writers don't know about restriction but implement what their compiler allows. Therefore when restrictions are really necessary it shall be possible to check them by tools (none of the compilers which we are using complains about the 'repeat' in the default behaviour ...)
- Any changes of part 1 may require additional changes of part 4.

Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
24-11-2010 12:09 | Wolfgang Seka | New Issue |
24-11-2010 12:09 | Wolfgang Seka | Clause Reference(s) | => Part 1 clause 20.4, part 4 and clause 7.5
24-11-2010 12:09 | Wolfgang Seka | Source (company - Author) | => stf160 - Wolfgang
30-11-2010 09:29 | Jacob Wieland - Spirent | Note Added: 0009835 |
30-11-2010 09:30 | Jacob Wieland - Spirent | Relationship added | related to 0005833
30-11-2010 09:32 | Ina Schieferdecker | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-11-2010 16:03 | Gyorgy Rethy | Note Added: 0009857 |
30-11-2010 16:03 | Gyorgy Rethy | Assigned To | => Jens Grabowski
30-11-2010 16:03 | Gyorgy Rethy | Status | new => assigned
30-11-2010 16:03 | Gyorgy Rethy | Target Version | => Edition 4.3.1 (not yet published)
01-12-2010 08:45 | Gyorgy Rethy | Note Edited: 0009857 |
01-12-2010 08:47 | Gyorgy Rethy | Note Edited: 0009857 |
03-12-2010 10:01 | Gyorgy Rethy | Target Version | Edition 4.3.1 (not yet published) => Edition 4.3.2 (interim)
24-05-2011 15:44 | Gyorgy Rethy | Note Added: 0010032 |
24-05-2011 19:29 | Gyorgy Rethy | Priority | normal => low
26-05-2011 14:41 | Gyorgy Rethy | Relationship deleted | related to 0005833
28-06-2011 11:11 | Jens Grabowski | Note Added: 0010131 |
28-06-2011 11:13 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
29-06-2011 14:33 | Gyorgy Rethy | Note Added: 0010146 |
29-06-2011 14:33 | Gyorgy Rethy | Status | assigned => closed
29-06-2011 14:33 | Gyorgy Rethy | Resolution | open => won't fix

Notes

(0009835)
Jacob Wieland - Spirent
30-11-2010 09:29

I think you are wrong in your assessment that 'break' behaves differently in interleave than in a nested alt statement.
If you have a nested alt statement where no statements are following the 'active' alt statement which contains the 'break' in the same block that contains that alt, then also the whole alt-tree is left by the break - same as for a top-level break in the interleave. If you have an alt-statement inside one branch of the interleave which contains a break, then of course only that alt-statement is left when the break is reached and not the whole interleave.
So, I would say the semantics of the break is the same for both and nothing has to be done in that regard.

(0009857)
Gyorgy Rethy
30-11-2010 16:03 (edited on: 01-12-2010 08:47)

STF discussion on 30-11-2010: repeat is allowed in activated defaults. Add a note clarifying this to Part-1 v4.3.1. All other possible changes to interleave is postponed to 2011.

(0010032)
Gyorgy Rethy
24-05-2011 15:44

Ask Wolfgang if allowing repeat in defaults solves STF160's problem.

(0010131)
Jens Grabowski
28-06-2011 11:11

Currently, there exists no problem with the restrictions for STF 160 (Wolfgang). A removal of the restrictions may require a new semantics, i.e., a replacement of the macro expansion by, e.g., parallel execution of the interleaved branches. Assigned to GyÃ¶rgy for closing.

(0010146)
Gyorgy Rethy
29-06-2011 14:33

Allowing repeat in interleave statements directly is not required by submitter and it has already been allowed in defaults invoked by the interleave.