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

ID | Project | Category | View Status | Date Submitted | Last Update
0005587 | Part 01: TTCN-3 Core Language | Clarification | public | 01-07-2010 15:10 | 15-12-2010 00:02

Reporter | Gyorgy Rethy |
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.3.1 (published 2011-06) | Fixed in Version | v4.3.1 (published 2011-06) |
Clause Reference(s) | ???
Source (company - Author) | STF160

Summary | 0005587: Clarification in using functions in special places

Description

Dear stf393,
another question for clarification:
we have several places in our test suite where in a receive event the return value of a function is used as parameter of the receive template,
e.g.
myPCO.receive(cr_Mytemplate(f_MyFunction(), ...))
Now in some cases f_MyFunction assigns a verdict and kills the PTC.
Even though this is not explicitly listed in 16.1.4 (or is this considered as a special case of inline template ??) acc. to the philosophy of 16.1.4 I tend to agree that this is not allowed.
Bute there are some thoughts which may be taken into consideration:
- When we have a variable getting assigned the function just before the receive statement and use this variable in the receive statement:
var MyType v_MyVar := f_MyFunction();
myPCO.receive(cr_Mytemplate(v_MyVar, ...))
That should work anyway - BUT "normal" programmers may not understand the difference and consider this as equivalent.
- Regarding the above examples: Is is it clearly specified (e.g. in part 4) at which point in time the function is performed when being parameter in the receive statement ??
- Currently there is poor support by tools to find this issues; just IBM raises an error
So as a summary: when there are restrictions on functions being used as parameters in receive statements acc. to 16.1.4 how can we achieve that people don't do it wrong ??
Please note, that this is also an issue of tool compatibility.
Thanks and regards
Wolfgang

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
01-07-2010 15:10 | Gyorgy Rethy | New Issue |
01-07-2010 15:10 | Gyorgy Rethy | Clause Reference(s) | => ???
01-07-2010 15:10 | Gyorgy Rethy | Source (company - Author) | => STF160
01-07-2010 15:12 | Gyorgy Rethy | Target Version | => Edition 4.3.1 (not yet published)
01-07-2010 17:18 | Gyorgy Rethy | Note Added: 0009457 |
01-07-2010 17:19 | Gyorgy Rethy | Note Edited: 0009457 |
01-07-2010 17:20 | Gyorgy Rethy | Note Edited: 0009457 |
30-08-2010 12:17 | Gyorgy Rethy | Status | new => assigned
30-08-2010 12:17 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
30-08-2010 13:55 | Jacob Wieland - Spirent | Note Added: 0009655 |
30-08-2010 17:22 | Jacob Wieland - Spirent | Note Added: 0009658 |
30-08-2010 17:24 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-09-2010 11:15 | Jens Grabowski | Note Added: 0009671 |
02-09-2010 09:27 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker
02-09-2010 09:27 | Gyorgy Rethy | Status | assigned => resolved
02-09-2010 09:27 | Gyorgy Rethy | Resolution | open => fixed
15-12-2010 00:01 | Ina Schieferdecker | Note Added: 0009974 |
15-12-2010 00:01 | Ina Schieferdecker | Status | resolved => closed
15-12-2010 00:02 | Ina Schieferdecker | Fixed in Version | => Edition 4.3.1 (not yet published)

Notes

(0009457)
Gyorgy Rethy
01-07-2010 17:18 (edited on: 01-07-2010 17:20)

STF discussion result is:
Passing a function as actual parameter to an object used in a receive statement is a use of the function at a special place just like the function was called directly in the receiving statement. Hence restrictions of $16.1.4 apply.
The STF agreed that the standard should be checked if all and every such cases are handled adequately.
"Is is it clearly specified (e.g. in part 4) at which point in time the function is performed when being parameter in the receive statement ??" -> it is not defined, as functions called during snapshot evaluation shall not change the snapshot, the exact time of evaluating the functions has no significance. Hence the restrictions of 16.1.4.
Checking those restrictions statically is not easy (for tool implementations). So, the STF should use the IBM tool for checking the quality of the code.
Even if "normal" programmers may not understand the difference, the case
var MyType v_MyVar := f_MyFunction();
myPCO.receive(cr_Mytemplate(v_MyVar, ...))
essentially differs from calling the function in the receive statement directly. A stand-alone receive is a shorthand for an alt with one receiving branch plus the activated defaults, thus stimulates a snapshot, while during a simple assignment there is no snapshot involved, i.e. no risk of side effects.

(0009655)
Jacob Wieland - Spirent
30-08-2010 13:55

The following sentence in section 16.1.4
"Value returning functions can be called during communication operations (in templates, template fields or in-line templates)"
should be changed to
"Value returning functions can be called during communication operations (in templates, template fields, in-line templates or as actual parameters)"
This way, all function calls that are used as actual parameters during communication operations must adhere to the non-side-effect restrictions.
(Actually, I think the already existent restriction 'in templates or in-line templates' already covers this as cr_Mytemplate(f_MyFunction(), ...) is a template and the f_MyFunction() call is part of that template expression, but being a bit more explicit doesn't hurt here, either)

(0009658)
Jacob Wieland - Spirent
30-08-2010 17:22

please review

(0009671)
Jens Grabowski
01-09-2010 11:15

Ok for me.

(0009974)
Ina Schieferdecker
15-12-2010 00:01

Implemented as proposed.