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

ID | Project | Category | View Status | Date Submitted | Last Update
0006423 | Part 01: TTCN-3 Core Language | Technical | public | 18-02-2013 11:19 | 28-08-2013 16:49

Reporter | Tomas Urban |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 16.1.4
Source (company - Author) | Elvior

Summary | 0006423: Restriction on communication operations in functions

Description

The chapter 16.1.4 states that "Value returning functions can be called in communication operations... To avoid side effects that cause changing the state of the component or the actual snapshot and to prevent different results of subsequent evaluations on an unchanged snapshot, the following operations shall not be used in functions called in the cases specified above."
I think the use of the expression "communication operations" is misfortunate and puts unnecessary restrictions on non-blocking operations. Operations like send, getcall etc. are never a part of snaphot evaluation. Therefore I suggest to change "communication operations" to "blocking communication operations".

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006511 | closed | Ina Schieferdecker | One more "special place" for function call
related to | 0006422 | closed | Ina Schieferdecker | Restrictions on operations invoked from special places

Attached Files |

Issue History
Date Modified | Username | Field | Change
18-02-2013 11:19 | Tomas Urban | New Issue |
18-02-2013 11:19 | Tomas Urban | Clause Reference(s) | => 16.1.4
18-02-2013 11:19 | Tomas Urban | Source (company - Author) | => Elvior
08-07-2013 15:40 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:43 | Jens Grabowski | Relationship added | related to 0006511
08-07-2013 15:43 | Jens Grabowski | Status | new => assigned
08-07-2013 15:43 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
08-07-2013 15:44 | Jens Grabowski | Relationship added | related to 0006422
08-07-2013 18:15 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06)
09-07-2013 11:38 | Jacob Wieland - Spirent | Note Added: 0011457 |
09-07-2013 16:12 | Jacob Wieland - Spirent | Note Added: 0011484 |
10-07-2013 15:30 | Jacob Wieland - Spirent | Note Added: 0011506 |
11-07-2013 10:19 | Jacob Wieland - Spirent | Status | assigned => confirmed
11-07-2013 10:48 | Jacob Wieland - Spirent | Status | confirmed => assigned
11-07-2013 10:48 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
28-08-2013 16:49 | Ina Schieferdecker | Status | assigned => resolved
28-08-2013 16:49 | Ina Schieferdecker | Resolution | open => fixed
28-08-2013 16:49 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
28-08-2013 16:49 | Ina Schieferdecker | Status | resolved => closed

Notes

(0011457)
Jacob Wieland - Spirent
09-07-2013 11:38

How about: "operations invoked during snapshot evaluation"?

(0011484)
Jacob Wieland - Spirent
09-07-2013 16:12

Actually, it should simply be disallowed to directly or indirectly call functions containing implicit or explicit alt statements (and all blocking operations written on their own are implicit alt statements) from the snapshot-evaluation part of an alt statement (i.e the guard or the event part).

(0011506)
Jacob Wieland - Spirent
10-07-2013 15:30

resolution proposal see CR6511