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

ID | Project | Category | View Status | Date Submitted | Last Update
0006731 | Part 01: TTCN-3 Core Language | Technical | public | 14-04-2014 11:34 | 04-01-2015 20:37

Reporter | Tomas Urban |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | N/A
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2014-06) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 5.4
Source (company - Author) | Elvior

Summary | 0006731: Passing parameters by reference

Description

It doesn't seem to be completely obvious, if inout parameters are passed by reference or if an assignment to a parameter is made when entering a parameterized context and another from the parameter when exiting the parameterized context.
Let's demonstrate the issue on the simple example:
type component C {
var integer vc_int := 0;
}
function f(inout intenger p_int) runs on C {
vc_int := 10;
log(p_int); // will it print 0 o 10?
}
testcase TC() runs on C {
f();
}
The definition in 3.1 seems to point in the direction of passing by reference: inout parameterization: kind of parameterization where the actual parameter is bound to the formal parameter when the parameterized object is invoked. However, there are other rules that seem to favour the other approach, e.g. the recently added restriction 5.4.2.j. This restriction wouldn't make much sense when passing by reference as it would simply pass the pointer to the original variable and the language contains means for checking if the value is defined (the isbound function). However, assignment of uninitialized values is forbidden, so the rule is perfectly justified for the two-way assignment interpretation.
I think it would be worth of considering to describe the mechanisms connected with inout assignments more exactly. Special attention should be paid to the situations when the inout parameters can be passed to external entities (and memory sharing typical for passing by reference is difficult to achieve) such as calling external functions, parameterized mapping etc. and sharing with testing code running in parallel (component.start call).
In case the decision is made in favour of passign by reference, it would be necessary to formalize rules for type compatibility and template/value compatibility. That's because when passing by reference, no value assignment actually takes place.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006813 | closed | Gyorgy Rethy | Passing fields or elements of a component variable as inout parameter

Attached Files

CR6731_resolution_v1.doc (94,720) 18-06-2014 12:20
http://oldforge.etsi.org/mantis/file_download.php?file_id=3047&type=bug
CR6731_resolution_v2.doc (98,816) 08-10-2014 11:32
http://oldforge.etsi.org/mantis/file_download.php?file_id=3111&type=bug
CR6731_resolution_v3.doc (166,400) 08-10-2014 13:50
http://oldforge.etsi.org/mantis/file_download.php?file_id=3114&type=bug
CR6731_resolution_v4.doc (166,400) 08-10-2014 16:40
http://oldforge.etsi.org/mantis/file_download.php?file_id=3122&type=bug
CR6731_resolution_v5.doc (175,616) 09-10-2014 09:27
http://oldforge.etsi.org/mantis/file_download.php?file_id=3124&type=bug
CR6731_resolution_v6.doc (175,616) 09-10-2014 11:05
http://oldforge.etsi.org/mantis/file_download.php?file_id=3125&type=bug
CR6731_resolution_v7.doc (179,200) 09-10-2014 15:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=3131&type=bug
CR6731_resolution_v8.doc (179,200) 04-11-2014 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=3152&type=bug
CR6731_resolution_v9.doc (180,736) 04-11-2014 11:22
http://oldforge.etsi.org/mantis/file_download.php?file_id=3155&type=bug

Issue History
Date Modified | Username | Field | Change
14-04-2014 11:34 | Tomas Urban | New Issue |
15-04-2014 09:19 | Jacob Wieland - Spirent | Note Added: 0012035 |
18-06-2014 09:04 | Gyorgy Rethy | Note Added: 0012118 |
18-06-2014 09:04 | Gyorgy Rethy | Assigned To | => Gyorgy Rethy
18-06-2014 09:04 | Gyorgy Rethy | Status | new => assigned
18-06-2014 09:04 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
18-06-2014 09:06 | Gyorgy Rethy | Note Edited: 0012118 | bug_revision_view_page.php?bugnote_id=12118#r33
18-06-2014 09:10 | Gyorgy Rethy | Note Edited: 0012118 | bug_revision_view_page.php?bugnote_id=12118#r34
18-06-2014 11:52 | Gyorgy Rethy | Note Edited: 0012118 | bug_revision_view_page.php?bugnote_id=12118#r38
18-06-2014 12:11 | Gyorgy Rethy | File Added: CR6731_resolution_v1.doc |
18-06-2014 12:16 | Gyorgy Rethy | Note Added: 0012121 |
18-06-2014 12:17 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
18-06-2014 12:17 | Gyorgy Rethy | Status | assigned => confirmed
18-06-2014 12:19 | Gyorgy Rethy | File Deleted: CR6731_resolution_v1.doc |
18-06-2014 12:20 | Gyorgy Rethy | File Added: CR6731_resolution_v1.doc |
18-06-2014 12:25 | Gyorgy Rethy | Note Edited: 0012118 | bug_revision_view_page.php?bugnote_id=12118#r39
18-06-2014 15:11 | Tomas Urban | Note Added: 0012130 |
18-06-2014 15:11 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
18-06-2014 15:11 | Tomas Urban | Status | confirmed => assigned
08-10-2014 08:25 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch
08-10-2014 08:31 | Gyorgy Rethy | Status | assigned => confirmed
08-10-2014 11:32 | Axel Rennoch | File Added: CR6731_resolution_v2.doc |
08-10-2014 11:35 | Axel Rennoch | Note Added: 0012278 |
08-10-2014 11:36 | Axel Rennoch | Assigned To | Axel Rennoch => Tomas Urban
08-10-2014 11:36 | Axel Rennoch | Status | confirmed => assigned
08-10-2014 11:36 | Axel Rennoch | Status | assigned => confirmed
08-10-2014 13:50 | Tomas Urban | File Added: CR6731_resolution_v3.doc |
08-10-2014 13:59 | Tomas Urban | Note Added: 0012283 |
08-10-2014 14:00 | Tomas Urban | Assigned To | Tomas Urban => Axel Rennoch
08-10-2014 16:08 | Axel Rennoch | Note Added: 0012294 |
08-10-2014 16:09 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
08-10-2014 16:09 | Axel Rennoch | Status | confirmed => assigned
08-10-2014 16:10 | Axel Rennoch | Status | assigned => confirmed
08-10-2014 16:25 | Jacob Wieland - Spirent | Note Added: 0012297 |
08-10-2014 16:29 | Jacob Wieland - Spirent | Note Added: 0012299 |
08-10-2014 16:40 | Gyorgy Rethy | File Added: CR6731_resolution_v4.doc |
08-10-2014 16:40 | Gyorgy Rethy | Note Added: 0012303 |
08-10-2014 16:41 | Gyorgy Rethy | Status | confirmed => resolved
08-10-2014 16:41 | Gyorgy Rethy | Resolution | open => fixed
08-10-2014 16:41 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)
09-10-2014 09:17 | Tomas Urban | Assigned To | Gyorgy Rethy => Tomas Urban
09-10-2014 09:17 | Tomas Urban | Status | resolved => feedback
09-10-2014 09:17 | Tomas Urban | Resolution | fixed => reopened
09-10-2014 09:27 | Tomas Urban | File Added: CR6731_resolution_v5.doc |
09-10-2014 09:28 | Tomas Urban | Note Added: 0012310 |
09-10-2014 09:28 | Tomas Urban | Status | feedback => assigned
09-10-2014 11:05 | Tomas Urban | File Added: CR6731_resolution_v6.doc |
09-10-2014 12:02 | Tomas Urban | Note Added: 0012315 |
09-10-2014 12:02 | Tomas Urban | Assigned To | Tomas Urban => Axel Rennoch
09-10-2014 12:02 | Tomas Urban | Status | assigned => confirmed
09-10-2014 13:13 | Jacob Wieland - Spirent | Note Added: 0012322 |
09-10-2014 15:14 | Tomas Urban | Note Added: 0012327 |
09-10-2014 15:43 | Tomas Urban | File Added: CR6731_resolution_v7.doc |
09-10-2014 15:47 | Tomas Urban | Note Added: 0012328 |
10-10-2014 08:51 | Axel Rennoch | Assigned To | Axel Rennoch => Tomas Urban
10-10-2014 08:51 | Axel Rennoch | Status | confirmed => assigned
10-10-2014 08:52 | Axel Rennoch | Note Added: 0012335 |
10-10-2014 08:52 | Axel Rennoch | Status | assigned => confirmed
10-10-2014 09:04 | Tomas Urban | Note Added: 0012338 |
10-10-2014 09:04 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
10-10-2014 10:07 | Jacob Wieland - Spirent | Note Added: 0012344 |
10-10-2014 10:38 | Tomas Urban | Note Added: 0012349 |
10-10-2014 10:38 | Tomas Urban | Note Edited: 0012349 | bug_revision_view_page.php?bugnote_id=12349#r85
10-10-2014 10:41 | Jacob Wieland - Spirent | Note Added: 0012350 |
10-10-2014 10:44 | Jacob Wieland - Spirent | Note Added: 0012353 |
10-10-2014 10:50 | Jacob Wieland - Spirent | Note Added: 0012354 |
03-11-2014 13:43 | Gyorgy Rethy | Note Added: 0012377 |
03-11-2014 15:19 | Jacob Wieland - Spirent | Note Added: 0012379 |
03-11-2014 16:14 | Gyorgy Rethy | Note Added: 0012383 |
03-11-2014 16:15 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
04-11-2014 08:50 | Tomas Urban | File Added: CR6731_resolution_v8.doc |
04-11-2014 08:50 | Tomas Urban | File Deleted: CR6731_resolution_v8.doc |
04-11-2014 09:26 | Tomas Urban | File Added: CR6731_resolution_v8.doc |
04-11-2014 09:35 | Tomas Urban | Note Added: 0012387 |
04-11-2014 09:35 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
04-11-2014 10:30 | Jacob Wieland - Spirent | Note Added: 0012390 |
04-11-2014 11:22 | Gyorgy Rethy | File Added: CR6731_resolution_v9.doc |
04-11-2014 11:23 | Gyorgy Rethy | Note Added: 0012392 |
04-11-2014 11:24 | Gyorgy Rethy | Status | confirmed => resolved
04-11-2014 11:24 | Gyorgy Rethy | Resolution | reopened => fixed
05-11-2014 07:57 | Tomas Urban | Assigned To | Gyorgy Rethy => Tomas Urban
05-11-2014 07:57 | Tomas Urban | Status | resolved => feedback
05-11-2014 07:57 | Tomas Urban | Resolution | fixed => reopened
05-11-2014 07:57 | Tomas Urban | File Added: CR6731_resolution_v10.doc |
05-11-2014 08:01 | Tomas Urban | Note Added: 0012411 |
05-11-2014 08:01 | Tomas Urban | Status | feedback => assigned
05-11-2014 08:01 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
05-11-2014 08:01 | Tomas Urban | Status | assigned => confirmed
05-11-2014 16:19 | Gyorgy Rethy | Relationship added | related to 0006813
05-11-2014 16:22 | Gyorgy Rethy | Note Added: 0012438 |
05-11-2014 16:23 | Gyorgy Rethy | File Deleted: CR6731_resolution_v10.doc |
05-11-2014 16:23 | Gyorgy Rethy | Status | confirmed => resolved
05-11-2014 16:23 | Gyorgy Rethy | Resolution | reopened => fixed
04-01-2015 20:37 | Gyorgy Rethy | Note Added: 0012612 |
04-01-2015 20:37 | Gyorgy Rethy | Status | resolved => closed

Notes

(0012035)
Jacob Wieland - Spirent
15-04-2014 09:19

I'm pretty sure the only way this can go in general is the assignment-semantics as otherwise, passing a variable of one type as an actual parameter to a formal parameter of a type-compatible type would probably be hard to achieve. However, if the types are the same, passing-by-reference is mostly equivalent to the assignment-semantics.

(0012118)
Gyorgy Rethy
18-06-2014 09:04 (edited on: 18-06-2014 12:25)

I agree with Jacob. Assignment-semantics was the original assumption, because TTCN-3 is an abstract language. It simply doesn't know things like pointer. We have references to active TTCN-3 objects only, like timers, components, ports, but not to data objects. Also, a term like passing-by-reference is not defined, so we should avoid using it.
I think the sources of the problem are
- using the word "bound" in the definitions of all kinds of parameterization; "bound" itself may be interpreted both as "assigning" and "connecting" and for in parameters it is used in the sense of "assigning" (otherwise it would be impossible to prevent changing the original value of the actual parameter), while for inout and out is used in the sense of "connecting";
- the definition of inout parameterization seems to be incomplete; i.e. it mentions nothing more than "bounding" the actual parameter to the formal parameter that really gives the impression of pointer-passing.
I suppose, in the example
testcase TC() runs on C {
f(vc_int);
}
was meant. Actually, according to Note1 to the definition of inout parameterization, the example shall print 10.
I will propose correction to the text.

(0012121)
Gyorgy Rethy
18-06-2014 12:16

See the proposed solution in CR6731_resolution_v1.doc.

(0012130)
Tomas Urban
18-06-2014 15:11

Result of STF discussion: the proposal should be more detailed. Possible improvements: - defining the term "passing by reference" and its implications - type compatibility rules for passing by reference (especially constraint handling) - some examples - check the situation in the existing TTCN-3 tools

(0012278)
Axel Rennoch
08-10-2014 11:35

- addition of an inital definition of "passing by reference" - extended note for "inout" and "out" parameterization

(0012283)
Tomas Urban
08-10-2014 13:59

Since Axel defined the term "passing by reference", I added it to several other rules so that the concept can be really used. I also defined what "passing by value" means. The terms are defined on an abstract level (no pointers and other implementation details are mentioned).
The system now resembles the one used in modern programming languages, the in and out parameterization use passing by value and inout passing by reference. Some current or proposed rules were not completely compatible with these concepts, so I had to modify them.
I also added an example demonstrating the difference between the two principles of parameter passing.
Axel, could you please check if there are no inconsistencies in my proposal? If so, we can continue our discussion if it is acceptable to solve the CR this way.

(0012294)
Axel Rennoch
08-10-2014 16:08

The proposal is fine for me. We may move the second sentence of the defintions "passing by .." to a NOTE.

(0012297)
Jacob Wieland - Spirent
08-10-2014 16:25

So, in my opinion it follows for inout parameterization that the type of the formal and actual parameter need to be the same, otherwise, there could develop some very confusing situations:
type integer I1 (0 .. 5);
type integer I2 (5 .. 10);
var integer i := 5;
f(i, i);
function f(inout I1 i1, inout I2 i2) {
i1 := 0; // causes an error because it violates constraint of I2
i2 := 10; // causes an error because it violates constraint of I1
}
I'm also not sure what happens if one actual parameter contains another one.
Consider the following:
type record R {
record {
integer i
} f
}
var R rr := ... ;
f2(rr, rr.f.i);
where f2 is defined like this
function f2(inout R r, inout integer i) {
r := { f := { i := x } } // is parameter i changed here or not?
i := i + 1; // does this still change r or not?
}

(0012299)
Jacob Wieland - Spirent
08-10-2014 16:29

Ah, the first restriction is already in the proposal, my bad. The other question still remains, though.

(0012303)
Gyorgy Rethy
08-10-2014 16:40

CR6731_resolution_v4.doc: only cosmetic editorial changes.

(0012310)
Tomas Urban
09-10-2014 09:28

I am afraid I have to reopen this CR. As Jacob pointed out there are unresolved questions regarding elements of structured types that are passed by reference. I tried to address these issues in the next version of the proposal. Jacob, if you have time, could you please take a look at it and comment it?

(0012315)
Tomas Urban
09-10-2014 12:02

Axel, could you please check the last additions to the proposed resolution?

(0012322)
Jacob Wieland - Spirent
09-10-2014 13:13

I would not know how to implement this (easily).
Also, if I understand it correctly, this would have the following implication.
type union U {
record {
integer i
} v1,
record {
float f
} v2
}
var U u := { v1 := { i := 5 } }
f(u, u.v1.i);
where
function f(U pu, integer pi) {
pu := { v2 := { f := 5.0 } } // => pi is undefined
pi := 5 // => pu == { v1 := { i := 5 } }
}
This, in my opinion, is highly uninituitive. It also breaks the rule that a variable that has been ininitalized cannot be un-initialized again.
I would define the semantics in such a way that pi keeps its value and does not have any impact on pu after pu was severed from pi anymore. pi can still be used inside the function, but is thrown away after f is left.
This is much more in sync with the copy-back approach that we interpreted the standard up-till now (and is also far easier to implement as pi does not have to know where it resides in its superstructure while in the proposed solution, it does to be able to do the appropriate expansion).

(0012327)
Tomas Urban
09-10-2014 15:14

Jacob, you understand the proposal correctly.
It is quite easy to implement using structured pointers. Instead of saving the address of the element itself, the tool can store the whole reference chain, i.e. in your example pi would be represented as { address of u, index of v2, index of i }. Dereferencing such pointers is not that fast as in case of classical pointers, but it should not constitute a major performance bottleneck.
I actually understand your concern that it is not intuitive. However, it is difficult to find any intuitive solution. When using copy-back approach, it behaves also in an unexpected way, especially for people used to passing by reference (and copying has other cons, such as wasting of resources).
There are two alternative approaches we could consider.
1) Element detaching instead of complete deleting. That's what Jacob proposes, i.e. that the elements that become disconnected from the original value (by omitting, truncating or selecting other variant) continue to live their own life after disconnection. That's the approach used for objects in languages with garbage collector, so the principle is quite well known. The question is if it is suitable for TTCN-3. I have some objections against this:
a) It doesn't seem to be intuitive either as restoring the original structure of the structured object doesn't reconnect the object.
b) We define passing by reference as sharing the data content by the actual and formal parameter, but this wouldn't apply in this case.
c) It might be difficult to implement in tools that do not use garbage collection (e.g. C++ based tools) as they would have to simulate garbage collector functionality.
d) It would require to change the definitions again and create additional rules.
2) References cannot be used after the referenced element is no longer valid. This is probably simpler to implement and explain in the rules, but a) and b) from the former paragraph are still valid.
In my opinion the proposed solution is the least "evil" one and I would pick it as the resolution of this CR. However, I am open to further discussion.

(0012328)
Tomas Urban
09-10-2014 15:47

Two small additions to the proposal (CR6731_resolution_v7.doc): - rules for using references in actual parameters - rules for order of passing values from out formal parameters to actual parameters

(0012335)
Axel Rennoch
10-10-2014 08:52

checked and can be set to resolved.

(0012338)
Tomas Urban
10-10-2014 09:04

Gyorgy, please take a final look at it before we mark it as resolved. Since Jacob raised some objections, a person different from the authors of the proposed changes should set the final verdict.

(0012344)
Jacob Wieland - Spirent
10-10-2014 10:07

I think the unintuitive-ness is my biggest concern, as well as the fact that we took great pains to introduce restrictions so that no variable that was at any point initialized can become uninitialized again.
This way, we introduce such a case through the back-door and what makes it worse, it is not apparent in the context of the variable at all (since the function does not know what its actual parameters will be) and can be caused by the assignment of a different variable. No flow-analysis checking for initialization of variables before usage would work anymore.
As non-garbage-collection frameworks have to take care of garbage-collection themselves, anyway, I am sure, it will be quite easy to find out that the reference to the variable is lost and therefore it can be collected (by whatever mechanism, if any) after the function is left again.
The unintuitive-ness of the non-reconnection-issue is granted, though I think only to those not thinking about implementations of data-structures. Both in the C-pointer-world as in the object-oriented-world no-one would expect a reconnect once a sub-structure is replaced with a different sub-structure. Anyway, if a NOTE explaining that special situation is added to the standard, confusion there can be avoided. This is, of course, true also for the other approach, but there the other drawbacks mentioned above are not addressed.

(0012349)
Tomas Urban
10-10-2014 10:38

Technically, we still don't allow to uninitialize variables. Only formal inout parameters can become uninitialized and only in cases when they refer to an element located in an optional part of a structured value. The existing tools most likely implement flow analysis in such a way that disappearance of the optional part of structured values is considered and I see no reason, why this approach cannot be extended to parameters passed by reference.
If you are concerned about the back door problem, we should first discuss if passing by reference is suitable at all, because this problem will always exist when two different references share the same data content.

(0012350)
Jacob Wieland - Spirent
10-10-2014 10:41

Thinking about this further, I think what you are proposing is actually called normally 'call-by-name', i.e. that in the parameterized body, the references to the formal-inout-parameters are replaced not by the references to the actual parameters but by the actual parameters themselves (i.e. the pu would be replaced by the expression u and pi would be replaced by the expression). That way, you would get your proposed semantics. This, of course, should not be called call-by-reference since those people knowing the term from other context will not understand the proposed call-by-name semantics. Thus, if you go that way - accepting all the drawbacks - please name and describe the concept accordingly.

(0012353)
Jacob Wieland - Spirent
10-10-2014 10:44

At the moment, no variable can become uninitialized by the disappearance of a sub-structure of another variable. So, flow-analysis tools do not have to take into account that a variable can become uninitialized, but only has to keep track of sub-structures. In principle, you are right, flow analysis is already pretty impossible even without this additional complication, but I don't think making it more complicated will help matters there.

(0012354)
Jacob Wieland - Spirent
10-10-2014 10:50

Of course, we could simply forbid this kind of situation altogether. I.e. passing a variable and a sub-structure of the same variable both as inout parameter to a function could be forbidden to avoid these semantic uncertainties. Though this might introduce backward-incompatiblities, the actual (probably pathological) situations where something like this occurs now are not clearly defined anyway and could lead to different behaviors in different tools, so I don't see a big problem there.
Thinking about this some more, we should also think about what happens if a variable and its sub-structure are passed to an inout and an out parameter. Does the out-copy-back-assignment win or lose according to parameter order or does copy-back always occur?

(0012377)
Gyorgy Rethy
03-11-2014 13:43

I think the main point is to define the rules clearly. At this point in time (TTCN-3 is 15 years old), we shall avoid backward incompatible restrictions.
Let discuss the possible alternatives further.
It seems to me that there is no disagreement regarding the unstructured case (new example 6). But, see below...
The complicated thing is when passing a structure and also its element as read-write-able parameters. I agree, from a (framework) function writer's point of view it may be strange and unexpected if some parameters can be made implicitly uninitialized by certain parameter combinations...
There are more ways to go:
- either specify a special exception for this case (too many exceptions already in the language)
- allow side effects, notify users about them.
- define a rule disallowing side effects in both cases (when the same value is passed to two different inout parameters and when a structure and its element are also passed as inout parameters), i.e. seemingly a value passed in, a value passed out, no side effect inside. This will complicate tool implementations but probably the safest for the users.
out parameters' behaviour should not be a problem, as they are passed by value, i.e. changing an out parameter within the called function shall not change the inout parameter's value immediately, within the function. An interesting effect that dependig on the above decision, it may or may not overwrite the inout parameter's (or its elemen's) value when leaving the function.

(0012379)
Jacob Wieland - Spirent
03-11-2014 15:19

I would opt for variant 3 (disallowing). It is a pathological case and will probably lead to unexpected behavior (and up till now, different behavior for each implementation). And, I think that this should include out parameters as well (mixing them with inout in a shared structure). If only out parameters are used, there is no problem.

(0012383)
Gyorgy Rethy
03-11-2014 16:14

STF discussion: passing a sructure and a member of that structure to two different inout parameters of a function at the same time should be disallowed.

(0012387)
Tomas Urban
04-11-2014 09:35

Modification in the last version of the document:
1. Restriction saying that elements of a structure cannot be passed by reference if the structure is also passed by reference.
2. Restriction saying that distinct alternatives of union and anytype values cannot be passed by reference.
These restrictions should prevent the situation when an already initialized inout parameter value becomes uninitialized through modification of another inout parameter.
I also removed the rules that were related to the now-disallowed behaviour and moved the section on structured values into the section describing actual parameters where it logically belongs.
Please review.

(0012390)
Jacob Wieland - Spirent
04-11-2014 10:30

No objections from me.

(0012392)
Gyorgy Rethy
04-11-2014 11:23

In CR6731_resolution_v9.doc only editorials and the new note to the actual parameter restrictions is deleted as superfluous, in agreement with Tomas.

(0012411)
Tomas Urban
05-11-2014 08:01

One more restriction is necessary to prevent the situation when both parent structure and its field/element are available as a reference: the combination of runs on and component variable field passed to an inout parameter. The restriction n) has been added to 5.4.2 and original restriction n) was changed to o). Please review.

(0012438)
Gyorgy Rethy
05-11-2014 16:22

It is agreed that a new restriction on component variabes has more chance to invalidate existing and working test suites, therefore we need user feedback on it. Hence it will not be included into this CR but new CR 6813 has been created. CR6731_resolution_v9.doc continues to be the final agreed version.

(0012612)
Gyorgy Rethy
04-01-2015 20:37

Added to V4.6.3