ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0007180 | Part 01: TTCN-3 Core Language | Technical | public | 17-09-2015 10:39 | 14-12-2015 14:58 |
|
| 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.7.1 (published 2015-06) | |
| Target Version | v4.8.1 (published 2016-07) | Fixed in Version | v4.8.1 (published 2016-07) | |
| Clause Reference(s) | 22.2.2 |
| Source (company - Author) | STF 487 |
|
| Summary | 0007180: Implicit from clause |
| Description | The current rules state that an error is produced when there's a mismatch between a target variable of a sender redirect assignment and the real sender (see e.g. the restriction 22.2.2.e.)
However, this situation can only happen in case the receiving statement contains no from clause or the from clause contains the all component construct. In my opinion, it would be more consistent with the general principles of alt statement evaluation if this situation produced just a mismatch, because the sender clause actually implicitly specifies the required type of the sender.
Thus:
var address v_sender;
p.receive -> sender v_sender
could be interpreted as:
p.receive from address:? -> sender v_sender
For that reason, I propose the following rule to be added to the section 22.2.2:
In case the receive statement contains a sender clause and the from clause is either missing or contains the any component notation, an implicit from clause is used instead, containing an AnyValue template of the same type as the variable referenced in the sender clause.
If accepted, a similar rule should be added to all remaining receiving statements (trigger, getcall, getreply, catch and check). |
| Steps To Reproduce | |
| Additional Information | |
| Tags | technically agreed |
| Relationships | |
| Attached Files |  CR7180_resolution_A_v1.docx (208,149) 13-10-2015 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3301&type=bug
CR7180_resolution_B_v1.docx (198,389) 13-10-2015 13:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3302&type=bug
CR7180_resolution_A_v2.docx (200,645) 14-10-2015 15:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=3308&type=bug
CR7180_resolution_A_v3.docx (209,829) 15-10-2015 08:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=3309&type=bug
CR7180_resolution_A_v4.docx (196,937) 02-11-2015 16:13
http://oldforge.etsi.org/mantis/file_download.php?file_id=3341&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 17-09-2015 10:39 | Tomas Urban | New Issue | |
| 21-09-2015 10:24 | Gyorgy Rethy | Target Version | => v4.8.1 (published 2016-07) |
| 22-09-2015 13:34 | Gyorgy Rethy | Tag Attached: technically agreed | |
| 22-09-2015 13:38 | Gyorgy Rethy | Note Added: 0013241 | |
| 12-10-2015 17:02 | Axel Rennoch | Assigned To | => Axel Rennoch |
| 12-10-2015 17:02 | Axel Rennoch | Status | new => assigned |
| 13-10-2015 13:14 | Axel Rennoch | File Added: CR7180_resolution_A_v1.docx | |
| 13-10-2015 13:14 | Axel Rennoch | File Added: CR7180_resolution_B_v1.docx | |
| 13-10-2015 13:18 | Axel Rennoch | Note Added: 0013370 | |
| 14-10-2015 11:54 | Gyorgy Rethy | Note Added: 0013382 | |
| 14-10-2015 15:28 | Axel Rennoch | File Added: CR7180_resolution_A_v2.docx | |
| 14-10-2015 15:39 | Axel Rennoch | Note Added: 0013388 | |
| 14-10-2015 15:40 | Axel Rennoch | Note Added: 0013389 | |
| 14-10-2015 15:40 | Axel Rennoch | Assigned To | Axel Rennoch => Jacob Wieland - Spirent |
| 14-10-2015 15:40 | Axel Rennoch | Status | assigned => acknowledged |
| 15-10-2015 08:44 | Jacob Wieland - Spirent | File Added: CR7180_resolution_A_v3.docx | |
| 15-10-2015 08:46 | Jacob Wieland - Spirent | Note Added: 0013390 | |
| 15-10-2015 08:46 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy |
| 15-10-2015 08:46 | Jacob Wieland - Spirent | Status | acknowledged => confirmed |
| 02-11-2015 16:13 | Gyorgy Rethy | File Added: CR7180_resolution_A_v4.docx | |
| 02-11-2015 16:15 | Gyorgy Rethy | Note Added: 0013448 | |
| 02-11-2015 16:15 | Gyorgy Rethy | Status | confirmed => resolved |
| 02-11-2015 16:15 | Gyorgy Rethy | Fixed in Version | => v4.8.1 (published 2016-07) |
| 02-11-2015 16:15 | Gyorgy Rethy | Resolution | open => fixed |
| 14-12-2015 14:58 | Gyorgy Rethy | Note Added: 0013623 | |
| 14-12-2015 14:58 | Gyorgy Rethy | Status | resolved => closed |
|
Notes |
|
|
|
|
STF discussion: Add a note to restriction e) describing what type mismatch in case of sender storing means. In general, rules applying to receiving operations in genera, like this one, should be moved to the genric clause of receiving ops. Check which rules could be moved to a common set of rules. |
|
|
|
|
Resolution A_v1 adds the several notes to the related restrictions.
Resolution B_v1 add one note only to 22.1.4.2 |
|
|
|
|
|
STF decision: if the from clause is missing, but the type of the sender can be determined, it shall be type compatible with the type of the variable. |
|
|
|
|
|
New version 2 for resolution A that does not introduce "implicit from" clauses but provides details on type mismatch for all sections with receiving statements. |
|
|
|
|
|
Please check CR7180_resolution_A_v2.docx |
|
|
|
|
because in the getcall, getreply, catch and check operations only the case where both a from and a sender clause is present was mentioned, I added another sentence for the case that a sender but no from clause is present.
please review and resolve |
|
|
|
|
|
CR7180_resolution_A_v4.docx: Little textual re-wording in clause 22.2.2 to eliminate "shall" from the note -> this text to be copied to the other clauses as well. |
|
|
|
|
|