TOPIC:

I'm a bit fuzzy on the semantics of out parameters: As far as I
understand 5.4.1 in the standard, the same type rules as for, say, in
parameters hold, that is, the type of the actual parameter has to be
compatible with the type of the formal parameter.

However, what happens to subtype restrictions? Consider the following
fragment:

type integer T1 (0 .. 255);

type record R1 {
T1 f
}

type record R2 {
integer f
}

function f(out R2 r) {
r.f := 1000;
}

...
var R1 r1;
f(r1);
...

Now, the assignment in f doesn't violate its formal parameter's type,
but it does violate the actual parameter's type. I assume the type
violation needs to be caught at some point, but when is that point?
Or did I misunderstand something?

Any help would be much appreciated!

--
Regards,
Mike

It occurred to me that I really meant inout parameters in the previous
post, so this would be the problematic construct:

type integer T1 (0 .. 255);

type record R1 {
T1 f
}

type record R2 {
integer f
}

function f(inout R2 r) {
r.f := 1000;
}

...
var R1 r1;
f(r1);
...

Sorry about the confusion.

--
Regards,
Mike Sperber

The issue described in the previous two messages really goes to the
deeper question of how parameter passing works for out and inout
parameters: Is it call-by-reference, or call-by-value-return, or
something else? For out parameters, the standard says that the
parameter seen by the callee is uninitialized. Would it be correct if
the caller just "zeroed out" the actual parameter, and then passed a
reference? (This would have different sharing semantics from creating a
fresh value and passing a reference to that for each out parameter.)

--
Regards,
Mike

Hi Mikael,

TTCN-3 is an abstract language, the storage and the content of the storage is not differentiated; hence values and templates does not have references and the terms "call-by-reference", "call-by-value" does not make sense; parameterization is described from the user point of view: what goes in, what goes back. All other is a tool implementation issue.

In another word, naturally, tools will implement inout and out parameters by passing references/pointers and in parameters by passing the value; but again, this is a tool internal issue, not the TTCN-3 terminology.

Regarding your previous mail, it is all the same if f() in the example uses inout or out formal parameters.

Unless a tool uses a complete flow analysis, it will fail only runtime, when trying returning from the call
f(r1);
It will try to assign the value 1000 to r1, which has a type constraint (0..255), therefore this assignment shall fail.

BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Monday, 28 July, 2008 4:50 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Out parameters vs. subtype restrictions
>
> The issue described in the previous two messages really goes
> to the deeper question of how parameter passing works for out
> and inout
> parameters: Is it call-by-reference, or call-by-value-return,
> or something else? For out parameters, the standard says
> that the parameter seen by the callee is uninitialized.
> Would it be correct if the caller just "zeroed out" the
> actual parameter, and then passed a reference? (This would
> have different sharing semantics from creating a fresh value
> and passing a reference to that for each out parameter.)
>
> --
> Regards,
> Mike
>

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> TTCN-3 is an abstract language, the storage and the content of the
> storage is not differentiated; hence values and templates does not
> have references and the terms "call-by-reference", "call-by-value"
> does not make sense; parameterization is described from the user point
> of view: what goes in, what goes back. All other is a tool
> implementation issue.

The differences between call-by-reference, call-by-value, and
call-by-value-return are all observable by the program. In particular,
the difference between sharing and not sharing is observable. Consider,
for example:

function f(inout integer a, inout integer b) return integer {
a := 5;
return b;
}

...
var integer x := 2;
f(x, x)

What does the call to f return? Ditto for out parameters. That's also
why the question of whether out parameters cause temporary variables to
be created at the call site is relevant.

> Unless a tool uses a complete flow analysis, it will fail only
> runtime, when trying returning from the call
> f(r1); It will try to assign the value 1000 to r1, which has a type
> constraint (0..255), therefore this assignment shall fail.

So is the check performed at the point of the assignment, or only upon
return from the function?

--
Regards,
Mike

Hello Michael,

Answers to your questions can be found in part 4 of the standard, clause 8.3.2.2. This explains the details of variable bindings.

<--- snip, TD --->
>
>function f(inout integer a, inout integer b) return integer {
> a := 5;
> return b;
>}
>
>...
> var integer x := 2;
> f(x, x)
>
>What does the call to f return? Ditto for out parameters.

The call to f as shown above would return the value 5. Following the terminology of part 4: The declaration of the variable x creates a location to store some value, and actually the value 2 is stored in that location. This location is passed to both parameters a and b of the function f. When executing the assignment a:=5 inside the function f, the value in this location is updated to be 5. Executing the return statement means to take the value of the location correspoding to b, as this is the location as for a, the value is 5.

The same reasoning applies when using out parameters instead of the inout parameters.

To investigate the question of type compatibility checks, let take three types Nat8, Nat16, and Nat32 corresponding to the non-negative natural numbers with an upper bound of 2^8-1, 2^16-1, and 2^32-1, respectively. Let's modify your example a little bit:

var Int16 x;

function f(inout Int32 a) return Int8 {
a := 512;
return a;
}

When executing the assignment a:=512, 512 would be stored in a location meant to hold a value between 0 and 2^16-1. This will be checked at this place, and the check would be ok. When executing the return statement it would be checked whether the value of a is of type Int8, which it isn't. In this example, there would be two checks.

Needless to say that the examples are quite artificial and users should not write such code anyway. Furthermore, a compiler or TTCN-3 analyzer should warn the user about the potential problems in the modified example.

<--- snip, TD--->

I hope this answers your questions.

>
>So is the check performed at the point of the assignment, or
>only upon return from the function?
>
>--
>Regards,
>Mike
>

Best regards

Thomas

---

|
| Thomas Deiß |
| Nokia Siemens Networks |
| Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
| Internal: 828 3584 |
| Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
| email: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

|

Thomas Deiss <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> Answers to your questions can be found in part 4 of the standard,
> clause 8.3.2.2. This explains the details of variable bindings.

Ah, I knew I'd overlooked something---now that I look at clause, I see I
marked this passage a few weeks ago. Thanks!

Now, one more question to make sure I really understand:

Let's say I change the parameters from "inout" to "out":

function f(out integer a, out integer b) return integer {
b := 1;
a := 5;
return b;
}

var integer x := 2; ... f(x, x) ...

Does f still return 5, as in the inout case? (I think not, but I'm not
sure.)

--
Regards,
Mike

Hi,

Technically the same answer is also given in Part-1; see note 2 to the definition of inout parameterization:
"inout parameterization: kind of parameterization where the value of the actual parameter is bound to the formal parameter when the parameterized object is invoked and the value of the formal parameter is passed back to the actual parameter, when the invoked object completes
NOTE 1: Inout parameters can be used for functions, altsteps, and test cases only.
NOTE 2: All changes to the arguments within the invoked object have effect on the arguments as seen by the invoking object."

Thus,
> > a := 5;
will "change the value" of x to five. Pls. note, in your example
> > return b;
does nothing, as you do not save the return value of the f(x,x) call.

Of course, a more tricky question would be the value of y after the function call
y := f(x, x);
Answer to this question, currently, can be found in Part-4 only, as described by Thomas.


BR, Gyorgy


>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Thomas Deiss
> Sent: Tuesday, 29 July, 2008 3:46 PM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Out parameters vs. subtype restrictions
>
> Hello Michael,
>
> Answers to your questions can be found in part 4 of the
> standard, clause 8.3.2.2. This explains the details of
> variable bindings.
>
> <--- snip, TD --->
> >
> >function f(inout integer a, inout integer b) return integer {
> > a := 5;
> > return b;
> >}
> >
> >...
> > var integer x := 2;
> > f(x, x)
> >
> >What does the call to f return? Ditto for out parameters.
>
> The call to f as shown above would return the value 5.
> Following the terminology of part 4: The declaration of the
> variable x creates a location to store some value, and
> actually the value 2 is stored in that location. This
> location is passed to both parameters a and b of the function
> f. When executing the assignment a:=5 inside the function f,
> the value in this location is updated to be 5. Executing the
> return statement means to take the value of the location
> correspoding to b, as this is the location as for a, the value is 5.
>
> The same reasoning applies when using out parameters instead
> of the inout parameters.
>
> To investigate the question of type compatibility checks, let
> take three types Nat8, Nat16, and Nat32 corresponding to the
> non-negative natural numbers with an upper bound of 2^8-1,
> 2^16-1, and 2^32-1, respectively. Let's modify your example a
> little bit:
>
> var Int16 x;
>
> function f(inout Int32 a) return Int8 {
> a := 512;
> return a;
> }
>
> When executing the assignment a:=512, 512 would be stored in
> a location meant to hold a value between 0 and 2^16-1. This
> will be checked at this place, and the check would be ok.
> When executing the return statement it would be checked
> whether the value of a is of type Int8, which it isn't. In
> this example, there would be two checks.
>
> Needless to say that the examples are quite artificial and
> users should not write such code anyway. Furthermore, a
> compiler or TTCN-3 analyzer should warn the user about the
> potential problems in the modified example.
>
> <--- snip, TD--->
>
> I hope this answers your questions.
>
> >
> >So is the check performed at the point of the assignment, or
> only upon
> >return from the function?
> >
> >--
> >Regards,
> >Mike
> >
>
> Best regards
>
> Thomas
>
>

---

|
> | Thomas Deiß |
> | Nokia Siemens Networks |
> | Heltorferstrasse 21, D-40472 Düsseldorf, Germany |
> | Internal: 828 3584 |
> | Mob: +49 151 5515 3584, tel: +49 211 9412 3584 |
> | email: This email address is being protected from spambots. You need JavaScript enabled to view it. |
>

---

|
>

György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:

> Technically the same answer is also given in Part-1; see note 2 to the
> definition of inout parameterization: "inout parameterization: kind of
> parameterization where the value of the actual parameter is bound to
> the formal parameter when the parameterized object is invoked and the
> value of the formal parameter is passed back to the actual parameter,
> when the invoked object completes NOTE 1: Inout parameters can be used
> for functions, altsteps, and test cases only. NOTE 2: All changes to
> the arguments within the invoked object have effect on the arguments
> as seen by the invoking object."

Right. I was mainly wondering about the interaction with subtyping.
Now, with out parameters, I was puzzled by this wording in the standard
(clause 5.4.1):

>> Although out parameters can be read within the parameterized object,
>> they do not inherit the value of their actual parameter; i.e. they
>> should be set before they are read.

Now I understand sharing is preserved even by out parameters. So, if I
do this:

function f(out integer a) {
// nothing
}

...
var integer x := 5;
f(x);
...

The value of x is undefined after the call, right? So calling a
function with an out parameter is the equivalent to using an inout
parameter, and filling the actual paramter with undefined values before
the call. Correct?

--
Regards,
Mike

Hi Mike,

Sorry for the delay, this discussion was not finished completely.
"> The value of x is undefined after the call, right? So
> calling a function with an out parameter is the equivalent to
> using an inout parameter, and filling the actual paramter
> with undefined values before the call. Correct?"

Taking the definition of out parameters literally, yes, this should happen. On the other hand, note 1 of 5.4.1 says:
"NOTE 1: Although out parameters can be read within the parameterized object, they do not inherit the value of their actual parameter; i.e. they should be set before they are read."

This can be understood that a value _shall_ be assigned to the formal parameter within f(), before returning from the function.

We have just discussed the issue in STF 349 and the conclusion was that we shall check the semantics of out parameterization, remove any possible ambiguity and increase clarity of the text if necessary. I wrote the following CR on the issue:
t-ort.etsi.org/view.php?id=3946

BR, Gyorgy

>

---

Original Message

---

> From: active_ttcn3 : mts stf133 ttcn version 3 - active
> members only [This email address is being protected from spambots. You need JavaScript enabled to view it.] On Behalf Of Michael Sperber
> Sent: Thursday, 31 July, 2008 8:08 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Out parameters vs. subtype restrictions
>
> György Réthy <This email address is being protected from spambots. You need JavaScript enabled to view it.> writes:
>
> > Technically the same answer is also given in Part-1; see
> note 2 to the
> > definition of inout parameterization: "inout
> parameterization: kind of
> > parameterization where the value of the actual parameter is
> bound to
> > the formal parameter when the parameterized object is
> invoked and the
> > value of the formal parameter is passed back to the actual
> parameter,
> > when the invoked object completes NOTE 1: Inout parameters
> can be used
> > for functions, altsteps, and test cases only. NOTE 2: All
> changes to
> > the arguments within the invoked object have effect on the
> arguments
> > as seen by the invoking object."
>
> Right. I was mainly wondering about the interaction with subtyping.
> Now, with out parameters, I was puzzled by this wording in
> the standard (clause 5.4.1):
>
> >> Although out parameters can be read within the
> parameterized object,
> >> they do not inherit the value of their actual parameter; i.e. they
> >> should be set before they are read.
>
> Now I understand sharing is preserved even by out parameters.
> So, if I do this:
>
> function f(out integer a) {
> // nothing
> }
>
> ...
> var integer x := 5;
> f(x);
> ...
>
> The value of x is undefined after the call, right? So
> calling a function with an out parameter is the equivalent to
> using an inout parameter, and filling the actual paramter
> with undefined values before the call. Correct?
>
> --
> Regards,
> Mike
>