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

ID | Project | Category | View Status | Date Submitted | Last Update
0005899 | Part 01: TTCN-3 Core Language | Clarification | public | 17-06-2011 11:45 | 17-07-2011 05:59

Reporter | Wolfgang Seka |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.3.2 (interim 2011) | Fixed in Version | v4.3.2 (interim 2011) |
Clause Reference(s) | 201 873-1 cl. 6.2.3
Source (company - Author) | stf160 - Wolfgang

Summary | 0005899: Clarification for partially initialised array

Description

Initialisation of "record of" is described in the core language in cl. 6.2.3.
Regarding uninitialised elements the core language says
"Undefined elements are permitted only in transient states (while the value remains invisible). Sending a record of or set of value with undefined elements shall cause a dynamic testcase error."
But seems not to be clearly specified what is meant with "transient states" or with the visibility of the value/element.
E.g. Assume we have a function initialing some array i.e. the function returns a "record of".
In this case at least one compiler raises a run-time error even though there is no access to any of the uninitialised fields:
v_MyArray := f_MyArray_PartialInit(); // => runtime error

Steps To Reproduce |
Additional Information | Note: If the above example would be not correct acc. the core language, from a users point of view there shall be a compilation error rather than a run-time error
Tags | No tags attached.
Relationships |
Attached Files | CR5899_resolution.doc (41,984) 01-07-2011 13:24 http://oldforge.etsi.org/mantis/file_download.php?file_id=2546&type=bug CR5899_resolution_v2.doc (56,832) 01-07-2011 16:47 http://oldforge.etsi.org/mantis/file_download.php?file_id=2554&type=bug CR5899_resolution_v3.doc (57,344) 04-07-2011 14:46 http://oldforge.etsi.org/mantis/file_download.php?file_id=2557&type=bug

Issue History
Date Modified | Username | Field | Change
17-06-2011 11:45 | Wolfgang Seka | New Issue |
17-06-2011 11:45 | Wolfgang Seka | Clause Reference(s) | => 201 873-1 cl. 6.2.3
17-06-2011 11:45 | Wolfgang Seka | Source (company - Author) | => stf160 - Wolfgang
22-06-2011 16:07 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
28-06-2011 10:55 | Jacob Wieland - Spirent | Note Added: 0010130 |
29-06-2011 09:07 | Gyorgy Rethy | Note Added: 0010134 |
30-06-2011 09:57 | Gyorgy Rethy | Severity | block => major
30-06-2011 11:14 | Gyorgy Rethy | Note Added: 0010154 |
30-06-2011 11:19 | Gyorgy Rethy | Note Edited: 0010154 |
30-06-2011 11:20 | Gyorgy Rethy | Status | new => assigned
30-06-2011 11:20 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
30-06-2011 14:36 | Gyorgy Rethy | Note Edited: 0010154 |
01-07-2011 13:24 | Jacob Wieland - Spirent | File Added: CR5899_resolution.doc |
01-07-2011 13:26 | Jacob Wieland - Spirent | Note Added: 0010175 |
01-07-2011 13:27 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
01-07-2011 16:47 | Gyorgy Rethy | Note Added: 0010190 |
01-07-2011 16:47 | Gyorgy Rethy | File Added: CR5899_resolution_v2.doc |
01-07-2011 16:48 | Gyorgy Rethy | Note Edited: 0010190 |
01-07-2011 16:48 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
04-07-2011 10:05 | Jacob Wieland - Spirent | Note Added: 0010205 |
04-07-2011 14:45 | Gyorgy Rethy | Note Added: 0010207 |
04-07-2011 14:46 | Gyorgy Rethy | File Added: CR5899_resolution_v3.doc |
04-07-2011 17:01 | Jacob Wieland - Spirent | Note Added: 0010208 |
05-07-2011 09:42 | Gyorgy Rethy | Note Added: 0010209 |
05-07-2011 12:40 | Jacob Wieland - Spirent | Note Added: 0010210 |
05-07-2011 14:37 | Gyorgy Rethy | Status | assigned => resolved
05-07-2011 14:37 | Gyorgy Rethy | Fixed in Version | => Edition 4.3.2 (interim)
05-07-2011 14:37 | Gyorgy Rethy | Resolution | open => fixed
05-07-2011 14:37 | Gyorgy Rethy | Note Added: 0010211 |
05-07-2011 14:37 | Gyorgy Rethy | Status | resolved => feedback
05-07-2011 14:37 | Gyorgy Rethy | Resolution | fixed => reopened
05-07-2011 14:38 | Gyorgy Rethy | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
05-07-2011 14:38 | Gyorgy Rethy | Status | feedback => resolved
05-07-2011 14:38 | Gyorgy Rethy | Resolution | reopened => fixed
05-07-2011 14:38 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
17-07-2011 05:59 | Ina Schieferdecker | Note Added: 0010223 |
17-07-2011 05:59 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010130)
Jacob Wieland - Spirent
28-06-2011 10:55

In a variable assignment there is an access to the uninitialized fields. When assigning the fields to the variable v_MyArray, each element must be copied. Therefore, it must be initialized.
There cannot be a compilation error because this cannot be checked at compile-time as the compiler cannot know in general what f_MyArray_PartialInit() does. So, it can at most generate a warning, but basically this warning would then have to be generated for almost all assignments of structured variables and thus would not be helpful. (Same problem as with index-checking).

(0010134)
Gyorgy Rethy
29-06-2011 09:07

It is not defined anywhere, that assigning a record of means copying of all elements one-by-one. This is just one - inefficient - way of doing that. Another way, e.g. to assign the pointer of the array returned by the function to the pointer of the variable. But this is just a side comment.
More importantly, I'm always in favor of checking whatever possible compile time. But once this case cannot be checked compile time, what is the sense of this restriction? This is just decreases usability and the only "benefit" is that completeness shall be checked before each assignment, instead of checking this once, before sending the value (or entering a library public function, depending of the use case).

(0010154)
Gyorgy Rethy
30-06-2011 11:14 (edited on: 30-06-2011 14:36)

Result of STF430's discussion on 30.06.2001:
Allow
-assigning not fully initialized structured values
-passing not fully initialized structured values as in parameter (inout and out are already allowed)
-returning not fully initialized structured values
-concatenate, rotate and shift not fully initialized structured values
The standard'd text shall be checked as this issue is handled at several places, so small text changes will be needed at several places; the whole text has to be checked for consistency.
Submit a CR to extend isvalue: return true if parameter is completely initialized and contains a value, return false in all other cases (e.g. for non-accessible fields or uninitialized parameter). Also ispresent and ischosen should be consistent with this.
Submit a CR on isbound.

(0010175)
Jacob Wieland - Spirent
01-07-2011 13:26

uploaded CR5899_resolution.doc, please review

(0010190)
Gyorgy Rethy
01-07-2011 16:47 (edited on: 01-07-2011 16:48)

I think that we agreed that uninitialized stuff cannot be returned as this would be a workaround to make already initialized stuff uninitialized again. This could be problematic both from the consistency and implementation point of view. Otherwise OK, some editorial changes, see CR5899_resolution_v2.doc. Pls. check.

(0010205)
Jacob Wieland - Spirent
04-07-2011 10:05

How would uninitializing stuff be possible when returning it is possible but assignment of the returned stuff is not possible?

(0010207)
Gyorgy Rethy
04-07-2011 14:45

Hi Jacob,
seems that we are saying the same. I have written earlier: "I think that we agreed that uninitialized stuff cannot be returned", thus returning uninitialized stuff shall NOT be allowed - we both claiming this. Ok, I can see, it has been corrected in the value variables clause but not in the template variable clause. I have corrected this, see text in CR5899_resolution_v3.doc for final review.

(0010208)
Jacob Wieland - Spirent
04-07-2011 17:01

No, we are not in agreement on this. We decided that returning uninitialized is not harmful in itself. If the function returns something which is then not used, why should that be an error. Thus, our philosophy was: only disallow that which can lead to an error. I.e. the assignment. Therefore, I restricted rhs of assignment to partially initialized. Sure, in most cases the effect is the same, but I would rather check this at runtime at the places of assignment than at all return-statements.
small example:
function f() return integer { var integer i; return i }
function g(integer x) { // does nothing with x }
why should g(f()) be an error?

(0010209)
Gyorgy Rethy
05-07-2011 09:42

Hi Jacob,
Because of consistency, not to have different rules for "all" the cases. Assignment lhs of assignment and a formal parameter are analogous things. In a similar way, rhs of the assignment, actual parameters and return values are also analugue things. Therefore the rules shall be the same at least for these categories not to overcomplicate the language for nothing.
I haven't heard any use case for that and no one requested such feature. So, we would solve a null problem, complicate the tools but adding again a specific rule ... that we should avoid.
Btw. not returning uninitialized value/template can be checked compile time with a limited effort, at least for the most usual cases (let me say 99%). Checking the assignment is really possible in runtime only - at least with reasonable effort.
So, you can see, the reasons are mainly not technical but rather usability issues.

(0010210)
Jacob Wieland - Spirent
05-07-2011 12:40

OK

(0010211)
Gyorgy Rethy
05-07-2011 14:37

As in CR5899_resolution_v3.doc.

(0010223)
Ina Schieferdecker
17-07-2011 05:59

Basically implemented as proposed.