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

(0013241)
Gyorgy Rethy
22-09-2015 13:38

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.

(0013370)
Axel Rennoch
13-10-2015 13:18

Resolution A_v1 adds the several notes to the related restrictions. Resolution B_v1 add one note only to 22.1.4.2

(0013382)
Gyorgy Rethy
14-10-2015 11:54

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.

(0013388)
Axel Rennoch
14-10-2015 15:39

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.

(0013389)
Axel Rennoch
14-10-2015 15:40

Please check CR7180_resolution_A_v2.docx

(0013390)
Jacob Wieland - Spirent
15-10-2015 08:46

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

(0013448)
Gyorgy Rethy
02-11-2015 16:15

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.

(0013623)
Gyorgy Rethy
14-12-2015 14:58

Added to draft V4.7.4