Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007195Part 01: TTCN-3 Core LanguageNew Featurepublic09-10-2015 15:2712-12-2016 20:28
ReporterJacob Wieland - Spirent 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Versionv4.9.1 (published 2017-05)Fixed in Versionv4.9.1 (published 2017-05) 
Summary0007195: interleave is much too restricted
DescriptionThe 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.
TagsNo tags attached.
Clause Reference(s)20.4
Source (company - Author)Testing Technologies - Jacob Wieland
Attached Filesdocx file icon CR-7195.docx [^] (21,380 bytes) 28-12-2015 11:27

- Relationships

-  Notes
(0013478)
Gyorgy Rethy (reporter)
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 (manager)
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 (manager)
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 (manager)
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 (manager)
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 (reporter)
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 (reporter)
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 (manager)
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 (reporter)
18-08-2016 08:24

 Implements STF decision, looks fine by me.
(0014399)
Gyorgy Rethy (reporter)
12-12-2016 20:28

 Added to draft V4.8.2

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker