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
0006678Part 01: TTCN-3 Core LanguageClarificationpublic04-02-2014 09:3206-01-2015 18:43
ReporterTomas Urban 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.7.1 (published 2015-06)Fixed in Versionv4.7.1 (published 2015-06) 
Summary0006678: Reference to omitted field in the right hand side of an assignment
DescriptionI am afraid the core language specification doesn't contain any specific guidelines for using a reference to an omitted field in the right hand side of an assignment. Theoretically it should not be allowed, because the restriction 17.1.a requires the RHS value to be a value or template and omit/reference to an omitted field is neither of those. However, I think that such an interpretation is too restrictive and probably no-one reads it this way. I have seen several ETSI test suites which don't follow this strict interpretation.

Therefore I propose to formalize the commonly accepted interpretation by amending the rules for assignment in the following way:

Modify the restriction a:
The right-hand side of an assignment shall evaluate to a value or template, which is type compatible with the variable at the left-hand side of the assignment or an omitted field or omit symbol.

Add restriction c:
If the right-hand side of an assignment contains an omitted field or omit symbol, the left-hand side shall contain a reference to an optional field or to a template variable.
TagsNo tags attached.
Clause Reference(s)17.1
Source (company - Author)Elvior
Attached Filesdocx file icon CR6678_v1.docx [^] (18,112 bytes) 09-04-2014 12:58
docx file icon CR6678_resolution_v2.docx [^] (18,922 bytes) 10-10-2014 08:57
docx file icon CR6678_resolution_v3.docx [^] (19,521 bytes) 10-10-2014 09:37
docx file icon CR6678_resolution_v4.docx [^] (19,602 bytes) 10-10-2014 11:05

- Relationships

-  Notes
(0011971)
Tomas Urban (developer)
09-04-2014 13:00

 Draft resolution created. No modifications to the restriction a were made as omit is syntactically a value. New restriction c specifies dedicated rules for handling omit or omitted field occurring in the RHS.
Please check the proposed resolution.
(0012057)
Jacob Wieland - Spirent (reporter)
30-04-2014 09:06

 I don't get it. Since when is 'omit' not a template? It can be used both for unrestricted templates and for templates with omit-restriction.

I think this additional restriction is just a special case of the restriction before it.
(0012058)
Jacob Wieland - Spirent (reporter)
30-04-2014 09:06

 But, of course, the case with the optional field in a non-template-variable is relevant.
(0012076)
Tomas Urban (developer)
16-06-2014 09:48

 The whole idea of the proposed restriction is to gather so far scattered or missing rules on handling the omit symbol and omitted non-template fields occuring on the RHS into one place. And you are right that the rule is mostly intended for non-template variables.

In case of templates occuring on the LHS, it describes the process how the overloaded omit literal and omitted field of a non-template variable become a matching symbol. The rule doesn't actually explicitly describe handling of the omit matching symbol on the RHS if the above mentioned transformation has already taken place. This is indeed covered by the restriction b.

I admit it might be partially overlapping with the restriction b, but the expression "reference to an omitted field" is mostly related to non-template variables. If you wish, I might extend this expression by adding "of non-template values" to it, but it will make the rule longer and won't give any actual benefit as there is actually no conflict with the restriction b.
(0012336)
Gyorgy Rethy (reporter)
10-10-2014 08:56

 See my proposal in CR6678_resolution_v2.docx.

My intention was to collect rules on template LHS-s in item b) and turn item c) out: when the LHS is a mandatory-kind value, omit and omitted fields are not allowed.

I also found unambiguous "contains a reference to", because {f1:=1, f2:=omit} contains reference to omit, but is a simple record/set value.

Please look at how do you like it this way.
(0012339)
Tomas Urban (developer)
10-10-2014 09:39

 I added a rule explaining the impact of referencing an omitted field on the right hand side of an assignment.
(0012343)
Gyorgy Rethy (reporter)
10-10-2014 09:50

 OK with me. If no comment from Jacob, in the next session can be set to resolved.
(0012355)
Jacob Wieland - Spirent (reporter)
10-10-2014 10:57

 I do not understand this sentence:

"c) If the left-hand side of the assignment is a reference to a non-optional value object (i.e. a value definition, a mandatory field, a record/set of/array element, a union alternative, a value parameter), the left-hand side shall not be a reference to an omitted field or the omit symbol."

Should the first 'left-hand side' not be 'right-hand side'?
(0012356)
Tomas Urban (developer)
10-10-2014 11:06

 The second one should be "right-hand side". Corrected in version 4.
(0012653)
Gyorgy Rethy (reporter)
06-01-2015 18:43

 Added to draft V4.6.3

- Issue History
Date Modified Username Field Change
04-02-2014 09:32 Tomas Urban New Issue
04-02-2014 09:32 Tomas Urban Clause Reference(s) => 17.1
04-02-2014 09:32 Tomas Urban Source (company - Author) => Elvior
07-04-2014 15:09 Gyorgy Rethy Assigned To => Tomas Urban
07-04-2014 15:09 Gyorgy Rethy Status new => assigned
08-04-2014 17:00 Gyorgy Rethy Target Version => v4.7.1 (published 2015-06)
09-04-2014 12:58 Tomas Urban File Added: CR6678_v1.docx
09-04-2014 13:00 Tomas Urban Note Added: 0011971
09-04-2014 13:49 Tomas Urban Assigned To Tomas Urban => Jens Grabowski
10-04-2014 11:08 Tomas Urban Status assigned => confirmed
30-04-2014 09:06 Jacob Wieland - Spirent Note Added: 0012057
30-04-2014 09:06 Jacob Wieland - Spirent Note Added: 0012058
16-06-2014 09:07 Jens Grabowski Assigned To Jens Grabowski => Tomas Urban
16-06-2014 09:07 Jens Grabowski Status confirmed => assigned
16-06-2014 09:48 Tomas Urban Note Added: 0012076
17-06-2014 14:14 Gyorgy Rethy Assigned To Tomas Urban => Gyorgy Rethy
06-10-2014 15:14 Gyorgy Rethy Status assigned => confirmed
10-10-2014 08:56 Gyorgy Rethy Note Added: 0012336
10-10-2014 08:57 Gyorgy Rethy File Added: CR6678_resolution_v2.docx
10-10-2014 08:58 Gyorgy Rethy Assigned To Gyorgy Rethy => Tomas Urban
10-10-2014 09:37 Tomas Urban File Added: CR6678_resolution_v3.docx
10-10-2014 09:39 Tomas Urban Note Added: 0012339
10-10-2014 09:39 Tomas Urban Assigned To Tomas Urban => Gyorgy Rethy
10-10-2014 09:50 Gyorgy Rethy Note Added: 0012343
10-10-2014 10:57 Jacob Wieland - Spirent Note Added: 0012355
10-10-2014 11:05 Tomas Urban File Added: CR6678_resolution_v4.docx
10-10-2014 11:06 Tomas Urban Note Added: 0012356
04-11-2014 11:28 Gyorgy Rethy Status confirmed => resolved
04-11-2014 11:28 Gyorgy Rethy Fixed in Version => v4.7.1 (published 2015-06)
04-11-2014 11:28 Gyorgy Rethy Resolution open => fixed
06-01-2015 18:43 Gyorgy Rethy Note Added: 0012653
06-01-2015 18:43 Gyorgy Rethy Status resolved => closed

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