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

ID | Project | Category | View Status | Date Submitted | Last Update
0005898 | Part 01: TTCN-3 Core Language | Clarification | public | 15-06-2011 16:50 | 01-12-2011 15:36

Reporter | Wolfgang Seka |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | 201 873-1 cl. 7.1 (??); 201 873-1 cl. 15.9
Source (company - Author) | stf160 - Wolfgang

Summary | 0005898: Clarification about comparision of optional fields with values
Description | It seems at least not to be obvious in the core language what happens when an optional field of a record is omit and it is used in comparision with a value ("=="); this causes a runtime error with at least one compiler therefore clarification is important for tool compatibility. Furthermore it would be quite costly to get a runtime error in this case.
Steps To Reproduce |

Additional Information

Example:
type record MyRecord_Type {
integer field1,
integer field2 optional
};
template (value) MyRecord_Type cs_MyRecord := {
field1 := 1,
field2 := omit
};
var MyRecord_Type v_MyRecord := valueof(cs_MyRecord);
=>
if (v_MyRecord.field2 == 3) { ... } /* shall be allowed i.e. the expression shall result in false and there shall be no runtime error */
if (v_MyRecord.field2 == omit) { ... } /* is this allowed ?? (would be equivalent "if (not ispresent(v_MyRecord.field2)) { ... }" or "if (not isvalue(v_MyRecord.field2)) { ... }" */
in principle there is the same situation with "!=" (but that can be derived from "not (... == ...)")
There is a similar situation in context of the match operation
if (match(v_MyRecord.field2, (2, 3))) { ... } /* I would assume that this is allowed but the standard says "The match operation allows to compare a value (specified in form of an expression) with a template" */

Tags | No tags attached.
Relationships |
Attached Files | CR5898_resolution_v2.doc (92,160) 30-09-2011 14:22 http://oldforge.etsi.org/mantis/file_download.php?file_id=2585&type=bug CR5898-proposal_v3.doc (121,856) 01-12-2011 10:29 http://oldforge.etsi.org/mantis/file_download.php?file_id=2638&type=bug

Issue History
Date Modified | Username | Field | Change
15-06-2011 16:50 | Wolfgang Seka | New Issue |
15-06-2011 16:50 | Wolfgang Seka | Clause Reference(s) | => 201 873-1 cl. 7.1 (??); 201 873-1 cl. 15.9
15-06-2011 16:50 | Wolfgang Seka | Source (company - Author) | => stf160 - Wolfgang
28-06-2011 16:26 | Gyorgy Rethy | Note Added: 0010133 |
28-06-2011 16:31 | Gyorgy Rethy | Note Edited: 0010133 |
28-06-2011 16:35 | Gyorgy Rethy | Note Edited: 0010133 |
28-06-2011 16:36 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
29-06-2011 12:45 | Gyorgy Rethy | Note Added: 0010142 |
29-06-2011 12:51 | Gyorgy Rethy | Note Edited: 0010142 |
30-06-2011 11:54 | Gyorgy Rethy | Note Added: 0010155 |
30-06-2011 14:23 | Gyorgy Rethy | Status | new => assigned
30-06-2011 14:23 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
27-09-2011 13:34 | Gyorgy Rethy | Target Version | => Edition 4.4.1
28-09-2011 16:23 | Gyorgy Rethy | Note Edited: 0010142 |
28-09-2011 16:25 | Gyorgy Rethy | Note Edited: 0010142 |
28-09-2011 16:25 | Gyorgy Rethy | Note Deleted: 0010155 |
30-09-2011 11:53 | Gyorgy Rethy | Note Added: 0010309 |
30-09-2011 11:53 | Gyorgy Rethy | File Added: CR5898_resolution_v1.doc |
30-09-2011 11:54 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
30-09-2011 13:59 | Jens Grabowski | Note Added: 0010312 |
30-09-2011 14:00 | Jens Grabowski | Note Added: 0010313 |
30-09-2011 14:01 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
30-09-2011 14:22 | Gyorgy Rethy | File Added: CR5898_resolution_v2.doc |
30-09-2011 15:01 | Gyorgy Rethy | Note Added: 0010316 |
30-09-2011 15:02 | Gyorgy Rethy | Note Edited: 0010316 |
30-09-2011 15:02 | Gyorgy Rethy | Note Edited: 0010316 |
30-09-2011 15:03 | Gyorgy Rethy | File Deleted: CR5898_resolution_v1.doc |
30-09-2011 15:03 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
01-10-2011 12:11 | Wolfgang Seka | Note Added: 0010321 |
30-11-2011 08:31 | Jacob Wieland - Spirent | Note Added: 0010411 |
30-11-2011 08:37 | Jacob Wieland - Spirent | Note Added: 0010412 |
30-11-2011 09:48 | Gyorgy Rethy | Note Added: 0010420 |
30-11-2011 14:27 | Gyorgy Rethy | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
01-12-2011 10:16 | Jacob Wieland - Spirent | File Added: CR5898-proposal_v3.doc |
01-12-2011 10:20 | Jacob Wieland - Spirent | Note Added: 0010461 |
01-12-2011 10:22 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-12-2011 10:23 | Jacob Wieland - Spirent | Assigned To | Gyorgy Rethy => Ina Schieferdecker
01-12-2011 10:29 | Jacob Wieland - Spirent | File Deleted: CR5898-proposal_v3.doc |
01-12-2011 10:29 | Jacob Wieland - Spirent | File Added: CR5898-proposal_v3.doc |
01-12-2011 15:35 | Ina Schieferdecker | Note Added: 0010488 |
01-12-2011 15:35 | Ina Schieferdecker | Status | assigned => resolved
01-12-2011 15:35 | Ina Schieferdecker | Resolution | open => fixed
01-12-2011 15:35 | Ina Schieferdecker | Fixed in Version | => Edition 4.4.1
01-12-2011 15:36 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010133)
Gyorgy Rethy
28-06-2011 16:26 (edited on: 28-06-2011 16:35)

The question is not strictly related to the equality operator itself. For consistency reasons, the two examples below shall behave the same way:
1) direct use
if (v_MyRecord.field2 == 3)...
2) use via parameterization
function f(in integer pl_int) return boolean {
return pl_int == 3
}
if(f(v_MyRecord.field2))...
Therefore the question is, if a pure integer value (parameter) can accept omit or not. The answer is clearly defined in clause 6.1.0:
"a) integer: a type with distinguished values which are the positive and negative whole numbers, including zero.
Values of integer type shall be denoted by one or more digits; the first digit shall not be zero unless the value is 0; the value zero shall be represented by a single zero."
There is no omit in the value set of the integer type and it cannot be assigned to integer. In another words, the above example 2) shall cause an error when calling function f() with a missing .field2 field. Therefore example 1) shall do the same.
Btw., any extension of the simple types with virtual "values" (like "omit") would cause performance degradation of the tools and increase the size of the generated code that may be critical in case of several telecom applications, as we have discussed earlier by email. I have asked our developers, it really would...
If clarification is felt to be needed, I propose to clarify this in the restrictions part of clause 7 (btw. it seems that restriction a) of clause 7 and restriction a) of clause 7.1 claims almost the same, in 7.1 it explicitly mentions that operands are values, but the two restrictions could be merged).

(0010142)
Gyorgy Rethy
29-06-2011 12:45 (edited on: 28-09-2011 16:25)

STF discussion on 29-06-2011: Comparision mechanism for structured value fields could be extended: in the first step the presence of corresponding fields could be checked; if any field present in one value is missing in the other value, equality returns false; if the corresponding present fields have equal values, equality returns true, otherwise it returns false.
Also, to solve the problem in the generic case isvalue() shall be extended to be error-safe, e.g. if a field inside an omitted field is referenced, it shall not cause an error -> A new CR on this has to be submitted.

(0010309)
Gyorgy Rethy
30-09-2011 11:53

Pls. review CR5898_resolution_v1.doc.

(0010312)
Jens Grabowski
30-09-2011 13:59

I am sorry, but I think that the resolution adds more confusion then clarification.
Either we handle OMIT like a value, or not.
If we handle OMIT like a value, OMIT values (e.g., optional record fields set to OMIT), can be freely used in relational operators. Even OMIT == OMIT will evaluate to true.
If we do not handle OMIT like a value, OMIT values can not be used in relational operators at all. E.g.,
type record MyRecord_Type {
integer field1,
integer field2 optional
};
template (value) MyRecord_Type cs_MyRecord := {
field1 := 1,
field2 := omit
};
if (v_MyRecord.field2 == 3) { ... } // will result in a runtime error
if (v_MyRecord.field2 == omit) { ... } // will also result in a runtime error
The current solution sometimes handles OMIT like a value and sometimes not.

(0010313)
Jens Grabowski
30-09-2011 14:00

Reassigned to GyÃ¶rgy for discussion.

(0010316)
Gyorgy Rethy
30-09-2011 15:01 (edited on: 30-09-2011 15:02)

Thinking it further, the case of comparing two omitted fields shall not be allowed. In this case the user shall check if at least one of the optional fields is present (writing a function for this is not really an issue. Otherwise the user will - and existing code does -, consider that the content of the optional field is a value and it may cause an error at other places anyway.
For example
type set S1 { integer a1 optional};
type set S2 { integer b1 optional, integer b2 optional };
type set S3 { integer c1 };
...
var S1 vl_S1 := { a1 := omit }
var S2 vl_S2 := { b1 := omit, b2 := 5 }
var S3 vl_S3 := { c1 := 3 }
...
if(S1.a1==S2.b1){P.send(S1.a1)}//send would cause an error
if(S1.a1==S2.b2){P.send(S1.a1)}//this will work in this case, because S2.b2 is present
if(S1.a1==S3.c1){P.send(S1.a1)}//this always will work
CR5898_resolution_v2.doc contains a proposed resolution according to this.
It needs STF discussion and decision.

(0010321)
Wolfgang Seka
01-10-2011 12:11

I don't understand why comparing two omitted fields shall not be allowed and I don't agree to this with a similar argument as by Jens: When I can compare an omitted field with another field there shall be no restriction. From telecommunication's point of view that even may make sense.
E.g. I receive message twice and want to check whether some field is the same in both message: "if (m1.field == m2.field)"
When this is allowed for optional fields in general and even when field is omitted in one of the messages people will not have in mind to separately handle the case of the field being omitted in both messages. => At some (later) point in time we will get a runtime error.
So - it is not the question whether this can easily avoided by e.g. some function or not.

(0010411)
Jacob Wieland - Spirent
30-11-2011 08:31

I don't think that mis-using the == operator to test for value-ness before sending (instead of the proper isvalue function) should be an argument to keep this restriction.
Also, if equality is not allowed on omit, then all your if-send statements would cause a runtime-error (at the == check) anyway. So, if existing code would really assume that this restriction existed before, then this would not be the way to exploit this.

(0010412)
Jacob Wieland - Spirent
30-11-2011 08:37

The CR resolution is unacceptable. Either comparison with omit is totally disallowed or totally allowed, but singling out the special case where almost EVERYONE intuitively would assume that it would be true to be an error does neither make sense nor does it help the user in any way avoid problems at runtime.
If comparison with omit would be disallowed totally, I would go so far as forbidding it even at static level, i.e. comparison with optional fields should then be disallowed, forcing the user to use valueof() around them to make it explicit that they are aware that the field might be omit and forcing them to check for presentness beforehand.
Still, I don't think this is the way to go.

(0010420)
Gyorgy Rethy
30-11-2011 09:48

From usability point of view you are correct. But in this case the wording shall be very cautious to emphasis that the operands of == and != are not only values but also the fields attribute that the field is absent.
The text says today:
""Operands of equality (==) and non-equality (!=) shall be values of the same root type and the values being compared ..."
this wording shall completely be re-phrased.
A note shall also be added saying, that if two fields are equal, this does not mean that they are present (i.e may not be values).
What about missing fields of different types?
type record MyRec { integer f1 optional, charstring f2 optional }
const MyRec c_myRec := { omit, omit }
...
if (c_myRec.f1 == c_myRec.f2 ) //???; true, false, error?
I think it shall be error (in whith case it can be checked compile time)

(0010461)
Jacob Wieland - Spirent
01-12-2011 10:20

implemented proposal to also allow comparison between field references and between field references and values. Still forbidden: omit == x, x == omit, omit == omit. For this ispresent() shall be used. Also amended the general restrictions part of Expressions section to be consistent with the Semantic Descriptions part.

(0010488)
Ina Schieferdecker
01-12-2011 15:35

Implemented as proposed.