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

ID | Project | Category | View Status | Date Submitted | Last Update
0007598 | Part 01: TTCN-3 Core Language | Technical | public | 26-01-2017 14:21 | 30-12-2017 15:40

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1 (published 2017-05) |
Target Version | v4.10.1 (published 2018-05) | Fixed in Version | v4.10.1 (published 2018-05) |
Clause Reference(s) | 5.4.1.2
Source (company - Author) | STF 521

Summary | 0007598: Invalid restriction on formal template parameters
Description | The restriction 5.4.1.2.b shall be changed, so that it does not mention functions and altsteps used in the component.start operation. This restriction is not present in the rules for formal value parameters (5.4.1.1.b) and the rules on starting a component explicitly mention that out and inout parameters are allowed and describe how they are handled in this case.
Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0007495 | closed | Gyorgy Rethy | out, inout and return value should be assignable via the done/killed statement redirect

Attached Files | CR7598-v1.docx (175,808) 08-09-2017 10:14 http://oldforge.etsi.org/mantis/file_download.php?file_id=3685&type=bug

Issue History
Date Modified | Username | Field | Change
26-01-2017 14:21 | Tomas Urban | New Issue |
18-04-2017 16:35 | szabados | Note Added: 0014577 |
02-05-2017 09:34 | Jacob Wieland - Spirent | Note Added: 0014611 |
06-06-2017 11:44 | Jens Grabowski | Relationship added | related to 0007495
06-06-2017 11:44 | Jens Grabowski | Note Added: 0014622 |
06-06-2017 11:45 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
06-06-2017 11:45 | Jens Grabowski | Status | new => assigned
08-09-2017 10:14 | Tomas Urban | File Added: CR7598-v1.docx |
08-09-2017 10:16 | Tomas Urban | Note Added: 0014825 |
08-09-2017 10:16 | Tomas Urban | Status | assigned => confirmed
24-10-2017 14:58 | Jacob Wieland - Spirent | Note Added: 0014852 |
24-10-2017 14:58 | Jacob Wieland - Spirent | Status | confirmed => resolved
24-10-2017 14:58 | Jacob Wieland - Spirent | Fixed in Version | => v4.9.1 (published 2017-05)
24-10-2017 14:58 | Jacob Wieland - Spirent | Resolution | open => fixed
24-10-2017 14:58 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-12-2017 15:40 | Gyorgy Rethy | Note Added: 0014956 |
30-12-2017 15:40 | Gyorgy Rethy | Status | resolved => closed
30-12-2017 15:40 | Gyorgy Rethy | Fixed in Version | v4.9.1 (published 2017-05) => v4.10.1 (published 2018-05)
30-12-2017 15:40 | Gyorgy Rethy | Target Version | => v4.10.1 (published 2018-05)

Notes

(0014577)
szabados
18-04-2017 16:35

On one hand yes, the limitation should be removed.
On the other hand using out and inout parameters in start does not make too much sense.
According to 21.3.2 inout parameters are to be treated like in parameters.
And out parameters remain unchanged by the started behaviour if the started behaviour changes it during its execution.
So by removing the limitation the standard becomes more consistent, and also more error prone.
Why is it allowed to start a function that has an out parameter, if the value can not be returned and also out parameters get unbound before the first statement is executed?
No information can go in or out this way.

(0014611)
Jacob Wieland - Spirent
02-05-2017 09:34

I think it is a matter freedom vs. correctness. On the one hand, the current situation allows you to use code that might not be intended for that use but is still sufficient for your needs, so you don't have to write a similar function.
On the other hand, it always leads to the situation that people are not aware of the current rule and are surprised by it, because they don't think of the deeper implications of how it would be otherwise.
Thus, it clearly violates the principle of least surprise and should be changed (if possible).

(0014622)
Jens Grabowski
06-06-2017 11:44

STF discussion: To be resolved with CR 7495

(0014825)
Tomas Urban
08-09-2017 10:16

Only the original issue has been resolved, the remaining problems will be resolved in the related CR 0007495. Please check.

(0014852)
Jacob Wieland - Spirent
24-10-2017 14:58

issue is resolved

(0014956)
Gyorgy Rethy
30-12-2017 15:40

Added to draft V4.9.2