ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006934 | Part 01: TTCN-3 Core Language | Clarification | public | 11-03-2015 14:20 | 07-08-2015 13:50

Reporter | Wolfgang Seka |
Assigned To | Gyorgy Rethy |
Priority | high | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2014-06) |
Target Version | v4.8.1 (published 2016-07) | Fixed in Version | v4.8.1 (published 2016-07) |
Clause Reference(s) | 15.9, B.1.2.8
Source (company - Author) | MCC160 - Wolfgang

Summary | 0006934: Unnecessary restriction on match operation
Description | By applying restrictions of B.1.2.8 on match operation a runtime error may be generated by tools when the second parameter of "match" is omit.
Steps To Reproduce |

Additional Information

Recently for some compiler an additional runtime check has been introduced causing runtime errors for match operations where never has been any issue before.
Apart from the general question what these kinds of checks shall be good for, a correction/clarification in the core language seems to be required to prevent tool vendors from introducing this kind of checks.
Clause 15.9 is describing the match operation as such and defines 2 additional restrictions:
a) first parameter shall not evaluate to a template
b) parameters shall be fully initialised.
Nevertheless there are further restrictions in B.1.2.8 - now being used as argument to generate a runtime error:
On one hand the title of B.1.2.8 is "Omitting optional fields" and the description is talking about omitting optional fields only. On the other hand restriction a) somehow includes templates to be omitted as such (this could be interpreted as a hint that this clause is applicable for templates and template variables too).
Restriction b) says "At the time of matching, it shall be applied to optional fields of record and set templates only" i.e. it does not say anything about templates as such what now is used as argument to raise a runtime error.
In the current case the above interpretation results in a runtime error e.g. for
function f_MyMatch(integer i, template (omit) integer p_Template) { return match(i, p_Template); }
when p_Template results in omit.
From a user's point of view this interpretation does not provide any benefit and therefore is useless.
In addition it could be argued whether the interpretation is applicable at all.
=> Clarification for 15.9 and/or B.1.2.8 is needed to allow operations like "match(someValue, omit)" (resulting in false).
Furthermore there are other cases for potential problems:
Assuming
type record MyRecord_Type { integer a, integer b optional };
var MyRecord_Type v_MyRecord := { 0, omit };
=>
match(v_MyRecord.b, 42); // shall not cause an error but result in false
match(v_MyRecord.b, omit); // shall not cause an error but result in true
In general there is the question whether "match" shall cause any runtime error at all (similar changes in the core language have been done e.g. for "ispresent" some years ago):
In case of any "error" match may simply return false and it is up to tool implementations to provide a user with additional information (if needed) about the mismatch by means of logging.

Tags | No tags attached.

Relationships

related to | 0007085 | closed | Gyorgy Rethy | Placeholder for the draft of V4.8.1

Attached Files |

Issue History
Date Modified | Username | Field | Change
11-03-2015 14:20 | Wolfgang Seka | New Issue |
12-03-2015 10:04 | Jacob Wieland - Spirent | Note Added: 0012832 |
13-03-2015 12:48 | Wolfgang Seka | Note Added: 0012833 |
13-03-2015 13:06 | Jacob Wieland - Spirent | Note Added: 0012834 |
13-05-2015 10:45 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
13-05-2015 10:45 | Gyorgy Rethy | Product Version | => v4.6.1 (published 2014-06)
13-05-2015 10:45 | Gyorgy Rethy | Target Version | => v4.8.1 (published 2016-07)
03-08-2015 14:19 | Gyorgy Rethy | Note Added: 0013036 |
03-08-2015 14:19 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
03-08-2015 14:19 | Gyorgy Rethy | Status | new => assigned
03-08-2015 14:21 | Gyorgy Rethy | Note Edited: 0013036 | bug_revision_view_page.php?bugnote_id=13036#r134
04-08-2015 09:41 | Gyorgy Rethy | Note Added: 0013046 |
04-08-2015 09:47 | Gyorgy Rethy | Resolution | open => fixed
04-08-2015 09:50 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 09:50 | Gyorgy Rethy | Status | assigned => confirmed
04-08-2015 10:56 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 10:56 | Jacob Wieland - Spirent | Status | confirmed => assigned
04-08-2015 10:57 | Jacob Wieland - Spirent | Note Added: 0013051 |
04-08-2015 10:59 | Jacob Wieland - Spirent | Note Added: 0013052 |
04-08-2015 13:34 | Gyorgy Rethy | Note Added: 0013058 |
04-08-2015 13:35 | Gyorgy Rethy | Note Edited: 0013058 | bug_revision_view_page.php?bugnote_id=13058#r143
04-08-2015 13:55 | Gyorgy Rethy | Note Added: 0013059 |
04-08-2015 13:56 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 13:56 | Gyorgy Rethy | Status | assigned => confirmed
04-08-2015 14:07 | Jacob Wieland - Spirent | Note Added: 0013060 |
04-08-2015 14:07 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
04-08-2015 14:07 | Jacob Wieland - Spirent | Status | confirmed => assigned
04-08-2015 17:24 | Gyorgy Rethy | Note Added: 0013073 |
04-08-2015 17:24 | Gyorgy Rethy | Relationship added | related to 0007085
04-08-2015 17:25 | Gyorgy Rethy | Note Added: 0013074 |
04-08-2015 17:26 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
04-08-2015 17:26 | Gyorgy Rethy | Status | assigned => confirmed
05-08-2015 10:50 | Jacob Wieland - Spirent | Note Added: 0013082 |
05-08-2015 10:50 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
05-08-2015 10:50 | Jacob Wieland - Spirent | Status | confirmed => assigned
06-08-2015 09:48 | Gyorgy Rethy | Note Added: 0013105 |
06-08-2015 09:48 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
06-08-2015 11:23 | Jacob Wieland - Spirent | Note Added: 0013111 |
06-08-2015 11:25 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
06-08-2015 13:07 | Jacob Wieland - Spirent | Note Edited: 0013111 | bug_revision_view_page.php?bugnote_id=13111#r147
07-08-2015 10:32 | Jacob Wieland - Spirent | File Added: es_20187301v040702_e.docx |
07-08-2015 10:35 | Jacob Wieland - Spirent | Note Added: 0013132 |
07-08-2015 10:35 | Jacob Wieland - Spirent | File Deleted: es_20187301v040702_e.docx |
07-08-2015 10:35 | Jacob Wieland - Spirent | File Added: es_20187301v040702_e.docx |
07-08-2015 10:37 | Jacob Wieland - Spirent | Note Added: 0013133 |
07-08-2015 10:37 | Jacob Wieland - Spirent | Status | assigned => confirmed
07-08-2015 13:37 | Gyorgy Rethy | File Deleted: es_20187301v040702_e.docx |
07-08-2015 13:40 | Gyorgy Rethy | Note Added: 0013146 |
07-08-2015 13:40 | Gyorgy Rethy | Status | confirmed => closed
07-08-2015 13:40 | Gyorgy Rethy | Fixed in Version | => v4.8.1 (published 2016-07)
07-08-2015 13:50 | Gyorgy Rethy | Note Edited: 0013146 | bug_revision_view_page.php?bugnote_id=13146#r149

Notes

(0012832)
Jacob Wieland - Spirent
12-03-2015 10:04

I disagree with the analysis that the standard is ambiguous or unclear:
The sentence "At the time of matching, it shall be applied to optional fields of record and set templates only" is clear (although we interpret this as meaning 'any entity which is allowed to be omit', i.e. also variables/parameters with modifier template(omit)). It is not used to justify the restriction of the definition of templates, just the restriction of the use of the match operation in the same way as implicit match-operations during receive-operations to be language-consistent.
The match operation is definitely "a time of matching".
I agree that, if the restriction is to be upheld, the same restriction should already be mentioned in the match operation restrictions section to be less "distributed" and confusing.
In general, I, too find the restriction totally unnecessary, as using an omit, * or ifpresent template to match a non-optional entity can have no detrimental effect whatsoever (which is why our tool supported this behavior before, even though it has been non-standard-conform for a long time), even though for 'omit' it is basically just a complicated way of writing 'false', but so is 1 == 2 and that is not disallowed either.
However, the conformance test suite introduced this problem by defining a testcase which checked this restriction which is why the runtime check has been introduced.
The above example of function f_MyMatch to make your case is problematic as there does not seem to be any clear reason why not simply the second parameter is defined as template(value) as it is used to match a value parameter which can never be omit anyway. A more useful use case would probably be more convincing.
Your example with the record type basically calls for an enlargement of the semantics of the match operation to also allow omit as the first actual parameter where at the moment only a value is allowed.

(0012833)
Wolfgang Seka
13-03-2015 12:48

Regarding ambiguity of the core language:
I don't care whether it is ambiguous, confusing, inconsistent or just useless - but it shall be corrected/changed.
Regarding the example:
f_MyMatch is given to illustrate the issue, not to convince anybody. But we have cases where some global variable can be omit (at the very beginning) or has a value and whenever it gets assigned a new value this shall be checked not to be the previous one (I know that this can done differently but that is not the point)
Apart from the above can I interprete your feedback in that way that in general you agree to change/enhance the language to allow the given examples ??

(0012834)
Jacob Wieland - Spirent
13-03-2015 13:06

Yes, as I have stated, we interpreted it for years in the way you desire and it was only changed in the current way because of enforcing standard conformity. I think this restriction is unnecessary.

(0013036)
Gyorgy Rethy
03-08-2015 14:19 (edited on: 03-08-2015 14:21)

STF discussion 03-08-2015: change restriction b) from "at the time of matching" to "at the time of matching during a receiving operation".

(0013046)
Gyorgy Rethy
04-08-2015 09:41

Proposed resolution is in the draft uploaded to CR 7085 (http://forge.etsi.org/mantis/view.php?id=7085 [^]), es_20187301v040702.docx, please cross-check.
One more restriction c) is added to close 15.9 that by intention is not putting new constraint to using match just saying explicitly what is agreed yesterday (omit and * can be used as template argument to match optional value fields). Please check if the text is unambiguous.

(0013051)
Jacob Wieland - Spirent
04-08-2015 10:57

Sorry, the new restriction contradicts exactly what we decided yesterday. The aim of the CR is to NOT have this restriction.

(0013052)
Jacob Wieland - Spirent
04-08-2015 10:59

The same restriction also is mentioned for the AnyValueOrNone matching mechanism (at the time of matching). so, to be consistent, it should also be changed there (the 'at the time of matching' part is written there several times and there are even examples that need to be changed accordingly - same as for Omit)

(0013058)
Gyorgy Rethy
04-08-2015 13:34 (edited on: 04-08-2015 13:35)

Jacob, I don't understand your first comment. My understanding is that we agreed yesterday that we allow these:
match(x.f, omit);//x is record/set, field f is optional
match(x.f, *);
[if you support them also for mandatory fields f, that's fine, but this is a TT extension]
but this doesn't make sense:
match(y, omit);//y is any type, not necessarily record/set
match(y, *);
and we haven't agreed to support them
exactly this is what restriction c) says.

(0013059)
Gyorgy Rethy
04-08-2015 13:55

es_20187301v040702_c.docx is uploaded to CR 7085. Please check it. If you don't agree, we will need a technical discussion.

(0013060)
Jacob Wieland - Spirent
04-08-2015 14:07

yes, and it is exactly this restriction that the CR addresses. The proposal is to LIFT this restriction, i.e. to ALLOW match(x, <something potentially being initialized to omit>), even in case that x is not a reference to an optional field or non-present template parameter/variable.
If you still do not want to allow this, then the standard does not need to be changed as that is exactly what the standard at the moment (though hidden in that "at the time of matching") already does.
This, though, will not address the concerns of those who issued this CR.

(0013073)
Gyorgy Rethy
04-08-2015 17:24

STF discussion 04-08-2015: allow matching any value (i.e. not only optional fields of values) to omit, like match(x,omit)//x is a value of any type; this matching will always return false.

(0013074)
Gyorgy Rethy
04-08-2015 17:25

See resolution in es_20187301v040702_b.docx in CR 7085. Please review.

(0013082)
Jacob Wieland - Spirent
05-08-2015 10:50

Sorry, the sentence
"Matching the value to the omit matching mechanism directly or by a TemplateInstance, which evaluates to omit, shall return false."
seems superfluous to me as that is already subsumed by the preceding sentence.
Also, it should already be described in the semantic description that the first argument may also denote an option field.
Also, to be consistent, what about a template(omit) parameter/variable/template?

(0013105)
Gyorgy Rethy
06-08-2015 09:48

"Matching the value to the omit matching ..." this sentence was the point of the whole many-days discussion. You think that e.g. an integer value can match to omit (and is unseccessful) "by default", others in the STF (including me) thinks that this comparision *in general* makes no sense. For this reason at the last discussion we have decided to create an explicit rule for this case to remove any ambiguity (and allow this kind of matching using match()). This sentence is exactly the explicit rule we have agreed to add.
Denote a field: this is obvious, as actual parameters can be fields.
Not only template(omit) can be compared to a (non-field) value, but any template to which the matching omit is assigned when passed to match()"... or by a TemplateInstance, which evaluates to omit..."; passing template(omit) is open to the users and it is a way to prevent possible runtime error - but shall not be mandatory.

(0013111)
Jacob Wieland - Spirent
06-08-2015 11:23 (edited on: 06-08-2015 13:07)

If you allow omit explicitly, then, of course, the semantics shall be the same matching semantics for omit as everywhere else (i.e. omit does only match an omitted field). So, of course, this additional sentence is superfluous in the context where omit is allowed also to be applicable to values (by the match operation).
Also, the semantic description for match operation at the moment still talks about a VALUE. As you cannot stop reiterating, an omitted field is not a value, therefore, a field-denotation referencing an optional field is also not a value in general, but can also be omit which would make it inapplicable to the match operation in its current description. Thus, the text needs to be changed to allow values and and optional field references also for the first argument. (If I have understood correctly that you want to allow this).
In your last paragraph in your last note, I think you are still talking about the right (template) argument to match(), while I am talking about the left (formerly value) argument to match().

(0013132)
Jacob Wieland - Spirent
07-08-2015 10:35

further text changes reflecting our current understanding on how the match operation should work. For consistency's sake, I also allowed template(omit) expressions as the expression argument of match as it has the same semantics as an optional value field.

(0013133)
Jacob Wieland - Spirent
07-08-2015 10:37

please review text on match operation. if approved, move proposal to CR 7085

(0013146)
Gyorgy Rethy
07-08-2015 13:40 (edited on: 07-08-2015 13:50)

Final text agreed in person, which is implemented in interim draft V4.7.3 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).