Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007180Part 01: TTCN-3 Core LanguageTechnicalpublic17-09-2015 10:3914-12-2015 14:58
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.7.1 (published 2015-06) 
Target Versionv4.8.1 (published 2016-07)Fixed in Versionv4.8.1 (published 2016-07) 
Summary0007180: Implicit from clause
DescriptionThe 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).
Tagstechnically agreed
Clause Reference(s)22.2.2
Source (company - Author)STF 487
Attached Filesdocx file icon CR7180_resolution_A_v1.docx [^] (208,149 bytes) 13-10-2015 13:14
docx file icon CR7180_resolution_B_v1.docx [^] (198,389 bytes) 13-10-2015 13:14
docx file icon CR7180_resolution_A_v2.docx [^] (200,645 bytes) 14-10-2015 15:28
docx file icon CR7180_resolution_A_v3.docx [^] (209,829 bytes) 15-10-2015 08:44
docx file icon CR7180_resolution_A_v4.docx [^] (196,937 bytes) 02-11-2015 16:13

- Relationships

-  Notes
(0013241)
Gyorgy Rethy (reporter)
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 (developer)
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 (reporter)
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 (developer)
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 (developer)
14-10-2015 15:40

 Please check CR7180_resolution_A_v2.docx
(0013390)
Jacob Wieland - Spirent (reporter)
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 (reporter)
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 (reporter)
14-12-2015 14:58

 Added to draft V4.7.4

- 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

MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker