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

ID | Project | Category | View Status | Date Submitted | Last Update
0005889 | Part 01: TTCN-3 Core Language | Technical | public | 25-05-2011 15:28 | 29-11-2013 12:35

Reporter | Jacob Wieland - Spirent |
Assigned To | Ina Schieferdecker |
Priority | low | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 6.2
Source (company - Author) | Jacob Wieland - Testing Technologies

Summary | 0005889: Usage as lvalue of fields of types which have subtype constraint which constrains the field should be forbidden

Description

If you have a situation like this:
type record Pair { integer i, integer j }
type Pair AllowedPair ({1, 2}, {2, 3})
function f() {
var AllowedPair x := {1, 2}
inc(x.i); // this should be an error
}
function inc(inout integer p) {
p := p + 1;
}
Then at runtime, this would lead to an invalid variable assignment to variable x which is probably not checked at runtime (because implementing this in general would mean that for every assignment all the subtype constraints of all the containing variables need to be checked) and thus can lead to problems.
Therefore, I propose to disallow any use as lvalues of field references constrained by a subtyping constraint of one of their ancestors, i.e. as the target variable in an assignment or as an inout or out parameter.
That means that such constrained records always have to be assigned in-bulk (by using structured value notations), at least for all the fields that are constrained by the subtyping constraints of their ancestors.
If a field is not constrained by an ancestor's subtyping constraint, it can still be normally used as lvalue.
Example:
type record R { integer k, integer i, integer j }
type R R2 ({ k:= 1, i := 2}, { k:= 2, i := 3})
function g() {
var R2 x := { 1, 2 }
x.k := 2; // error
inc(x.i); // error
inc(x.j); // allowed
x.j := 5; // allowed
}

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | es_20187301v040205m_CR5889.doc (14,848) 26-05-2011 16:22 http://oldforge.etsi.org/mantis/file_download.php?file_id=2510&type=bug CR5889_resolution_v1.doc (76,800) 14-10-2013 11:55 http://oldforge.etsi.org/mantis/file_download.php?file_id=2934&type=bug

Issue History
Date Modified | Username | Field | Change
25-05-2011 15:28 | Jacob Wieland - Spirent | New Issue |
25-05-2011 15:28 | Jacob Wieland - Spirent | Clause Reference(s) | => 6.2
25-05-2011 15:28 | Jacob Wieland - Spirent | Source (company - Author) | => Jacob Wieland - Testing Technologies
26-05-2011 16:04 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR5889.doc |
26-05-2011 16:04 | Jacob Wieland - Spirent | Note Added: 0010091 |
26-05-2011 16:21 | Jacob Wieland - Spirent | File Deleted: es_20187301v040205m_CR5889.doc |
26-05-2011 16:22 | Jacob Wieland - Spirent | File Added: es_20187301v040205m_CR5889.doc |
26-05-2011 16:22 | Jacob Wieland - Spirent | Status | new => assigned
26-05-2011 16:22 | Jacob Wieland - Spirent | Assigned To | => Gyorgy Rethy
26-05-2011 16:23 | Jacob Wieland - Spirent | Note Edited: 0010091 |
27-05-2011 15:21 | Gyorgy Rethy | Note Added: 0010105 |
27-05-2011 15:33 | Gyorgy Rethy | Note Edited: 0010105 |
28-06-2011 16:38 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
30-06-2011 09:30 | Gyorgy Rethy | Note Edited: 0010105 |
27-09-2011 13:57 | Gyorgy Rethy | Target Version | => Edition 4.4.1
30-11-2011 10:32 | Gyorgy Rethy | Priority | normal => low
30-11-2011 10:37 | Gyorgy Rethy | Note Added: 0010426 |
30-11-2011 10:37 | Gyorgy Rethy | Target Version | Edition 4.4.1 => v4.7.1 (published 2015-06)
13-07-2012 15:47 | Gyorgy Rethy | Note Added: 0010935 |
16-07-2012 10:40 | Jacob Wieland - Spirent | Note Added: 0010937 |
08-07-2013 18:20 | Gyorgy Rethy | Target Version | v4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
11-10-2013 15:22 | Gyorgy Rethy | Note Added: 0011786 |
11-10-2013 15:23 | Gyorgy Rethy | Note Edited: 0011786 |
11-10-2013 15:23 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 16:13 | Jacob Wieland - Spirent | Note Added: 0011789 |
11-10-2013 16:19 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 16:19 | Jacob Wieland - Spirent | Status | assigned => confirmed
14-10-2013 10:59 | Gyorgy Rethy | Note Added: 0011800 |
14-10-2013 11:55 | Gyorgy Rethy | File Added: CR5889_resolution_v1.doc |
14-10-2013 11:55 | Gyorgy Rethy | Note Edited: 0011800 |
14-10-2013 11:55 | Gyorgy Rethy | Status | confirmed => assigned
14-10-2013 11:55 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
14-10-2013 12:36 | Gyorgy Rethy | Status | assigned => confirmed
14-10-2013 13:12 | Jacob Wieland - Spirent | Status | confirmed => assigned
14-10-2013 13:12 | Jacob Wieland - Spirent | Note Added: 0011802 |
14-10-2013 13:12 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
14-10-2013 13:12 | Jacob Wieland - Spirent | Status | assigned => confirmed
29-11-2013 12:31 | Ina Schieferdecker | Note Added: 0011866 |
29-11-2013 12:31 | Ina Schieferdecker | Status | confirmed => resolved
29-11-2013 12:31 | Ina Schieferdecker | Resolution | open => fixed
29-11-2013 12:35 | Ina Schieferdecker | Status | resolved => closed
29-11-2013 12:35 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)

Notes

(0010091)
Jacob Wieland - Spirent
26-05-2011 16:04 (edited on: 26-05-2011 16:23)

Added concrete proposal. Please review.

(0010105)
Gyorgy Rethy
27-05-2011 15:21 (edited on: 30-06-2011 09:30)

I know that we talked about this, but... when considering the issue, this would mean that constrained structured types can be used to define constants and templates only...; I would say it is quite rare that the user assignes values for the complete structured variable only but never to its fields...; quite the opposite, structured variables are commonly used to construct the value at runtime step-by-step. So, the user will not be able to define parameterized templates for the type, dynamic construction of values/templates would be impossible, what about in parameters (disallowing inout and out only would - again - create a very specific exception in the language) and last but not least would also limit valid uses, when the value assigned to a field is in line with the constraint of the type.
This needs further consideration in the STF.

(0010426)
Gyorgy Rethy
30-11-2011 10:37

CR is not reporting a problem or unsupported use case, due to the limited time remaining in 2011 it shall be shifetd to 2012.

(0010935)
Gyorgy Rethy
13-07-2012 15:47

Checked the ASN.1 to TTCN-3 mapping and there are cases when ASN.1 type constraints are translated to TTCN-3 list subtyping for ASN.1 SEQUENSE and SET (TTCN-3 record and set). Introducing the change requested in this CR would make such ASN.1 definitions almost unable from TTCN-3 as well.

(0010937)
Jacob Wieland - Spirent
16-07-2012 10:40

I guess you meant "unusable". If so, could you give an example, as I cannot think of one.

(0011786)
Gyorgy Rethy
11-10-2013 15:22 (edited on: 11-10-2013 15:23)

Part-7 table 4:
Type Single Value Contained Subtype (h)
Sequence list list
Set list list
contained subtype is a relatively popular construct in ASN.1.
Today it is possible and allowed to change just one field of a variable based on such an imported ASN.1 type. But the point is, that a limitation of this kind would be non-backward compatible.
As we cannot agree on accepting the proposal, either we can agree on closing the CR with not fixed as we escalate it to MTS.

(0011789)
Jacob Wieland - Spirent
11-10-2013 16:13

Maybe we should find out if any of the existing tools are even aware of the problem and deal with it properly. I.e. it is very easy to produce values that violate the restrictions even though this can only be caught at runtime and only via quite complicated checking (which I am almost sure no tool does).
Since closing the CR would leave the problem thus unresolved, I think an escalation to MTS would then be the way to go.
As a compromise, we could, of course, at least (like we did for the non-determinism of initializing templates) strongly advise against such usages (as the potentially problematic places can be determined statically) so that
a) people become aware of the potential problem
b) tools have an incentive to check for those situation

(0011800)
Gyorgy Rethy
14-10-2013 10:59 (edited on: 14-10-2013 11:55)

I agree, a warning (note in the standard and even an example) would be useful. But we cannot forbid ALL usage, because it CAN also be used in a wrong way. See proposed resolution in CR5889_resolution_v1.doc.

(0011802)
Jacob Wieland - Spirent
14-10-2013 13:12

As a compromise, I guess this suffices.

(0011866)
Ina Schieferdecker
29-11-2013 12:31

as proposed in CR5889_resolution_v1.doc