ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0006491 | Part 01: TTCN-3 Core Language | Technical | public | 27-03-2013 18:55 | 29-08-2013 07:56 |
|
| Reporter | Wolfgang Seka | |
| Assigned To | Ina Schieferdecker | |
| Priority | normal | Severity | major | 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) | e.g. 11.1 |
| Source (company - Author) | MCC160 - Wolfgang |
|
| Summary | 0006491: At least some compiler generate a runtime error when a function returns an unititialised variable even in cases when the result |
| Description | There are cases where e.g. due to maintenance on existing TTCN-3 code a function is enhanced to return a value just for special cases, i.e. a function which has not had a return value before gets a return statement which is needed for some particular case.
Now it may happen that the function is just changed for the particular case when the return value is expected but for the other cases it e.g. returns an unitialised variable.
From a user's point of view that would not harm as in these cases the caller of the function does not evaluate the functions's result at all.
Nevertheless acc. to the restrictions in clause 11.1 of part 1 this is not allowed.
BUT - it seems that compilers cannot find that a compile time (or at least not for all cases).
But since some compilers are "improved" now to check this formal correctness at runtime, errors occur at runtime even though from a user's perspective there is no error.
As there is no way to detect that kind of problems before it comes to the runtime error and the code is even logically correct these errors are very costly.
=> either the restrictions regarding the return statements shall be reduced to allow returning uninitialised variables as long as they are not used by the caller or other proposals are requested about how these kind of problems can be avoided. |
| Steps To Reproduce | |
| Additional Information | MCC160 would like to participate on any discussions about this topic. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR6491.doc (164,352) 28-08-2013 13:51
http://oldforge.etsi.org/mantis/file_download.php?file_id=2869&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 27-03-2013 18:55 | Wolfgang Seka | New Issue | |
| 27-03-2013 18:55 | Wolfgang Seka | Clause Reference(s) | => e.g. 11.1 |
| 27-03-2013 18:55 | Wolfgang Seka | Source (company - Author) | => MCC160 - Wolfgang |
| 05-04-2013 09:49 | Jacob Wieland - Spirent | Note Added: 0011408 | |
| 05-04-2013 10:57 | Wolfgang Seka | Note Added: 0011409 | |
| 08-07-2013 14:56 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language |
| 08-07-2013 14:56 | Jens Grabowski | Status | new => assigned |
| 08-07-2013 14:56 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent |
| 08-07-2013 17:12 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06) |
| 10-07-2013 19:33 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy |
| 11-07-2013 09:05 | Jacob Wieland - Spirent | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent |
| 12-07-2013 08:58 | Jacob Wieland - Spirent | Note Added: 0011566 | |
| 12-07-2013 09:01 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker |
| 12-07-2013 09:01 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 15-07-2013 10:43 | Wolfgang Seka | Note Added: 0011580 | |
| 27-08-2013 14:26 | Ina Schieferdecker | Status | confirmed => assigned |
| 27-08-2013 14:26 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jacob Wieland - Spirent |
| 27-08-2013 14:33 | Gyorgy Rethy | Note Added: 0011609 | |
| 27-08-2013 14:34 | Gyorgy Rethy | Note Edited: 0011609 | |
| 28-08-2013 13:51 | Jacob Wieland - Spirent | File Added: CR6491.doc | |
| 28-08-2013 13:52 | Jacob Wieland - Spirent | Note Added: 0011624 | |
| 28-08-2013 13:52 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker |
| 28-08-2013 13:52 | Jacob Wieland - Spirent | Status | assigned => confirmed |
| 29-08-2013 07:55 | Ina Schieferdecker | Note Added: 0011630 | |
| 29-08-2013 07:55 | Ina Schieferdecker | Status | confirmed => resolved |
| 29-08-2013 07:55 | Ina Schieferdecker | Resolution | open => fixed |
| 29-08-2013 07:55 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06) |
| 29-08-2013 07:56 | Ina Schieferdecker | Status | resolved => closed |
|
Notes |
|
|
|
|
As I said in the meeting, I would opt for lifting the restriction on return statements since the assignment of an uninitialized value to a variable will catch such a behavior as well. It should be clear, though that this can lead to the situation where the result of a function is used directly as an actual parameter (where uninitialized values are allowed) of another function which then could lead to a runtime-error very far away from the error-cause. This makes the error-cause hard to locate, which is very costly, as well. Thus, there is no ideal solution for this problem, it has to be decided which scenario is more probable and thus more costly. |
|
|
|
|
As already mentioned in the earlier discussions - it is up to tools whether/how to provide the user with additional information and warnings at runtime and how to configure that; it is up to users whether to make use of this information and to configure the runtime environment accordingly. But the core language as such shall be independent of this and in particular it shall not mandate generation of runtime errors where - from a user's point of view - there is no problem at all.
Furthermore in this context the argumentation "... This makes the error-cause hard to locate ..." is not applicable as it is a tool issue how to verify and debug the code. |
|
|
|
|
After a lengthy discussion, the STF still thinks that the dangers of lifting this restriction outweigh the benefits the STF160 would gain.
In some cases it is possible to check statically, if a return value is initialized or not (after a potentially very costly analysis), but in lots of cases it can only be determined at runtime. Other languages solve this problem by restricting the language even further, so that the data-flow analysis becomes feasible; but then they forbid scenarios statically (the maybe-cases) some of which would never be a problem at runtime. Thus, they force the user - without specific necessity - to write more complicated code. This requirement in TTCN-3 is more implicit but still there.
Also, during the discussion, it was strongly opposed to make the semantic rules of the return statement context-dependent, i.e. depending on the place the given function is called. This would be a wrong language design.
The instruments to solve similar problems when a function is extended are given by the language itself, for instance by the isbound() predefined function. It can be used to check the to-be-returned variable before returning it and then return a dummy value in the case it is not initialized. Another way of preventing such errors is to use unit-testing for functions or to impose a coding style that initializes all variables at declaration. |
|
|
|
|
Mail set to stf460 (12 July 2013 09:11):
"I've seen the note added to 6491 in I don't think that it is the right decision and I think from a user's point of view it is not acceptable:
You are shifting tool problems from the tooling side to the user's side: There is no reason why cannot raise a warning at runtime (but that is a tool issue) but by raising a runtime the problem is definitely at the user's side.
Again please note that the issues causing problems are not visible for the user when writing the code therefore the user will not use any "instruments by the language itself" until there is a runtime error.
I hope that this is NOT a final decision." |
|
|
|
(0011609)
|
|
Gyorgy Rethy
|
27-08-2013 14:33
(edited on: 27-08-2013 14:34) |
|
STF discussion 2013-08-27: we should allow returning uninitialized value by a function, but this shall not be assigned to a variable or used in expression, ( but can be passed as parameter where uninitialized actual parameter is allowed)
|
|
|
|
|
|
added proposal, simply lessened the restriction for use of uninitialized variables to allow return statements. |
|
|
|
|
|