Hello all,

In a discussion the problem appeared, whether uninitialized variables can be assigned to other variables. Consider the following example, the question is whether the assignment is correct or whether a run-time error should occur.

module test14 {

control {
var integer x,y;
x:= y;
}
}

The standard version 2.2.1, clause 10, contains the following statement: 'Use of uninitialized variables at runtime shall cause a test case error'. In my understanding 'use' includes the occurrence in expressions as in the example below.
But there are other, more loose, interpretations of the term 'use', according to which the assignment above would not cause a run-time error.

The standard contains some other statements about partially defined values, e.g. arrays, where only some elements are defined.

Section 6.3.3, third paragraph between examples 1 and 2:

... If the value of the element notated by the index at the right-hand of an assignment is undefined, this shall cause a semantical or run-time error...

to my understanding, the following example would cause a run-time error

control {
var integer x, y;
var integer z[3];
z[0] := 1;
x := z[0]; // fine, this element has been defined
x := z[1]; // an error according to the statement cited above
x := y; // the case we are discussing about
x := y * 1; // an error because the undefined value would be used
}

In my opinion, if assigning uninitialized elements of an array is explicitly disallowed, then assignment of unitialized variables would also be disallowed. At least for basic types as the integer in the examples above. I cannot see the advantage of assigning unitialized variables. This would result in 'deinitializing' variables that have a value.

It would also create subtle questions like what is the meaning of the boolean expression y == y in case that y is undefined. Is this true or is this a run time error?

Next step: What is the meaning of
x := y;
if ( x == y ) {...
This could be a run-time error in the assignment,
a run-time error in the boolean expression,
or the boolean expression could be true.

These examples are just to highlight that there are problems if 'use' unitialized variables is interpreted not in a strict way.

I know that there are other persons having arguments in favor of allowing assignment of uninitialized variables. Opinions from other persons are also welcome.

Best regards

Thomas

---

| Thomas Deiß, Nokia Research Center Street address: |
| P.O. Box 101823 Meesmannstrasse 103 |
| D-44718 Bochum, GERMANY D-44807 Bochum, GERMANY |
| Phone: +49 234 984 2217 (int. 8272217) |
| Fax: +49 234 984 3491 (int. 8273491) |
| E-mail: This email address is being protected from spambots. You need JavaScript enabled to view it. |

---

Hi Thomas,

referencing an unitialized variable on the Right Hand Side (RHS) of an
assignment, or in any
expression, should be an error. Detected either during static semantic
verification, or
at run-time. The standard, as you indicate says that this should be detected
at run time,
but there are certain instances of usage, as the first example, which can be
easily
detected during static semantic verification during the parsing process.




control {
var integer x,y;
x:= y;
}

Any unitialized variable, or array element has no meaning (semantics) or
undefined semantics if you wish.

It would also create subtle questions like what is the meaning of the boolean
expression
y == y in case that y is undefined. Is this true or is this a run time error?

If y is unitialized, then it is an error. Reference to an unitialized
variable or constant in
an expression (not on the LHS (left hand side) of an assignment) is an error.

>I know that there are other persons having arguments in favor of allowing
assignment of >uninitialized variables. Opinions from other persons are also
welcome.

Heresy. What use would it be to allow this? Does anyone have a good example
of why
this might be advantageous?

Maybe the smartest thing to do would be to replace the word 'use' with
'reference' or
some clearer term.

'Use of uninitialized variables at runtime shall cause a test case error'.

'Reference to unitialized variables/constants/array indexes on the RHS of an
expression,
(assignment, boolean, logical, relational, etc. ) shall cause a test case
error. One might
even go further and indentify which classes of errors should be detected
statically, or
dynamically, but that is for the tool manufacturers or?

Cheers,


Claude.



Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hi Thomas, Claude, et al,

principally we see advantages of having a strict rules on unitialized
variables. However, in the context of language translations to TTCN-3
where definitions are structurally mapped onto TTCN-3 translations the
need arises exactly for this "lazy evaluation of assignments" where

control {
var integer x, y;
var integer z[3];
z[0] := 1;
x := z[0]; // fine, this element has been defined
x := y; // needed because of structural mappings
x := z[1]; // to be allowed because of similarity to the case before
x := y * 1; // an error because the undefined value is used
}

The current problem is that there is no mean to check whether a variable
is unitialized or not. If TTCN-3 would e.g. offer the ability to check
this one would not need this lazy assignment. Then, one would be able to
denote

if (z[0]!=undef) { x := z[0]; }
if (y!=undef) { x := y; }
if (z[1]!=undef) { x := z[1]; }
if (y!=undef) { x := y * 1; }

Now, to an example where we need the lazy assignment (as the TTCN-3
standard is currently open on this it is a legal interpretation) - or
the ability for an undef element in TTCN-3 (would require a CR to
TTCN-3). Another option would be to have a universal null value for
arbitrary types so that every variable can be initialized with this
value (would also require a CR to TTCN-3).

In TTCN-2 there are test case variables with the following
characteristics: "A test suite may make use of a set of variables which
are declared globally to the test suite but whose scope is defined to be
local to the Test Case. In concurrent TTCN, each test component,
including the MTC, receives a fresh copy of all Test Case Variables when
it is created. ... In the CREATE construct, PCO identifiers and CP
identifiers are passed to a PTC by textual substitution, as is usual in
the ATTACHment of Test Steps. All others parameters are passed by value.
This is done to prevent side effects on variables which could affect the
processing of other PTCs, causing unrepeatable results."

To be honest, this "fresh copy" is also a grey zone in TTCN-2. If
"fresh" means initialized to their initial/default values and
unitialized if no such value exist, we would have also no problem in the
TTCN-3 case. However, another part in TTCN-2 talks about "Once a Test
Case Variable has been bound to a value, the Test Case Variable will
retain that value until either it is bound to a different value, or
execution of the Test Case terminates - whichever occurs first. "

Taking this literally means that a created PTC needs to get the current
values of test case variables from the MTC (only the MTC creates PTCs in
TTCN-2). Now, a translator between TTCN-2 to TTCN-3 works structurally.
In order to provide these fresh copies it has to pass the current TCV
values into the test component and to bind it to the local TCVs of
created test components. The MTC starts the test component behavior by
parameterizing it with the TCV values. This behavior then binds at the
beginning the local TCV (e.g. to be placed as variables in the test
component type definition) to these current values - leading us to the
case of x:=y - and apparently, such a value can still be
undefined/unitialized, which causes problems as the lazy assignments are
in a grey zone of TTCN-3 (not explicitly allowed and not explicitly
forbidden) and/or as their is no ability to check for uninitialized
variables and/or their is no ability to define default values (e.g. a
null) to variables of whatever type.

Besides this subtle question on TTCN-2, I argue that TTCN-3 needs either
- lazy assignment
- the undef check
- the null value

Undef or null would be a clean solution, but require a CR to TTCN-3.
Lazy assignment is currently not forbidden, but is problematic.

With best regards,

Ina.


Claude Desroches wrote:
>
> Hi Thomas,
>
> referencing an unitialized variable on the Right Hand Side (RHS) of an
> assignment, or in any
> expression, should be an error. Detected either during static semantic
> verification, or
> at run-time. The standard, as you indicate says that this should be
> detected at run time,
> but there are certain instances of usage, as the first example, which
> can be easily
> detected during static semantic verification during the parsing process.
>
>
>
>
> control {
> var integer x,y;
> x:= y;
> }
>
> Any unitialized variable, or array element has no meaning (semantics) or
> undefined semantics if you wish.
>
> It would also create subtle questions like what is the meaning of the
> boolean expression
> y == y in case that y is undefined. Is this true or is this a run time
> error?
>
> If y is unitialized, then it is an error. Reference to an unitialized
> variable or constant in
> an expression (not on the LHS (left hand side) of an assignment) is an
> error.
>
> >I know that there are other persons having arguments in favor of
> allowing assignment of >uninitialized variables. Opinions from other
> persons are also welcome.
>
> Heresy. What use would it be to allow this? Does anyone have a good
> example of why
> this might be advantageous?
>
> Maybe the smartest thing to do would be to replace the word 'use' with
> 'reference' or
> some clearer term.
>
> 'Use of uninitialized variables at runtime shall cause a test case error'.
>
> 'Reference to unitialized variables/constants/array indexes on the RHS
> of an expression,
> (assignment, boolean, logical, relational, etc. ) shall cause a test
> case error. One might
> even go further and indentify which classes of errors should be detected
> statically, or
> dynamically, but that is for the tool manufacturers or?
>
> Cheers,
>
>
> Claude.
>
>
>
> Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> 685 Cedar Point Road phone: +1 705 533 23 94
> Penetanguishene, Ontario
> Canada
> L9M 1R3
>
> Solonplatz 3 phone: +49 30 9606 7986
> 13088 Berlin
> Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

Hello all,

as Ina has pointed out there is a grey area in TTCN-2. May I suggest that we first make this area less grey before argueing about TTCN-3 or even changing it based on a grey area in TTCN-2.

For easier reference, the parts cited by Ina are from Clauses 11.8.3 and 4 from ISO/IEC 9646-3. I am using the 1998 version of the standard.

Clause 11.8.4 defines when a test case variable is bound:

"Initially Test Case Variables are unbound. They may become bound (or be re-bound) in the following contexts:
a) at the point of declaration if an initial value is specified;
b) when the Test Case appears on the left-hand side of an assignment statement (see 15.10.4).
Once a Test Case Variable has been bound to a value, the Test Case Variable will retain the that value until either it is bound to a different value, or execution of the Test Case terminates - whichever occurs first. At termination of the Test Case, the Test Case Variable becomes re-bound to its initial value, if one is specified, otherewise it becomes unbound.
If an unbound Test Case Variable is used in the right-hand side of an asssignment, then it is a test case error."

The standard just mentions two ways when a test case variable is bound: At declaration, we are not talking about this here. Or in an assignment, we are not talking about this here either. The standard does not talk about binding a Test Case Variable on a PTC by binding the Test Case Variable on the MTC before the CREATE statement.

Also, the standard requires in 11.8.3 to create a fresh copy of a test case variable for each test component. Not just a copy, but a fresh copy. I understand this as a new instance of the variable, but not as a copy of the test case variable on the MTC including its value. But I can be wrong here.

I admit that my arguments do not rule out Ina's understanding. But at least I have serious doubts whether Ina's is the correct one. I would greatly appreciate it if somebody with more TTCN-2 expertise could help us to make this grey area more white.

Best regards

Thomas

>

---

Original Message

---

> From: ext Ina Schieferdecker
> [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: Thursday, April 03, 2003 6:31 AM
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Assignment of uninitialized variables
>

<- parts of other emails deleted, TD ->

>
> In TTCN-2 there are test case variables with the following
> characteristics: "A test suite may make use of a set of
> variables which
> are declared globally to the test suite but whose scope is
> defined to be
> local to the Test Case. In concurrent TTCN, each test component,
> including the MTC, receives a fresh copy of all Test Case
> Variables when
> it is created. ... In the CREATE construct, PCO identifiers and CP
> identifiers are passed to a PTC by textual substitution, as
> is usual in
> the ATTACHment of Test Steps. All others parameters are
> passed by value.
> This is done to prevent side effects on variables which could
> affect the
> processing of other PTCs, causing unrepeatable results."
>
> To be honest, this "fresh copy" is also a grey zone in TTCN-2. If
> "fresh" means initialized to their initial/default values and
> unitialized if no such value exist, we would have also no
> problem in the
> TTCN-3 case. However, another part in TTCN-2 talks about "Once a Test
> Case Variable has been bound to a value, the Test Case Variable will
> retain that value until either it is bound to a different value, or
> execution of the Test Case terminates - whichever occurs first. "
>
> Taking this literally means that a created PTC needs to get
> the current
> values of test case variables from the MTC (only the MTC
> creates PTCs in
> TTCN-2). Now, a translator between TTCN-2 to TTCN-3 works
> structurally.
> In order to provide these fresh copies it has to pass the current TCV
> values into the test component and to bind it to the local TCVs of
> created test components. The MTC starts the test component behavior by
> parameterizing it with the TCV values. This behavior then binds at the
> beginning the local TCV (e.g. to be placed as variables in the test
> component type definition) to these current values - leading us to the
> case of x:=y - and apparently, such a value can still be
> undefined/unitialized, which causes problems as the lazy
> assignments are
> in a grey zone of TTCN-3 (not explicitly allowed and not explicitly
> forbidden) and/or as their is no ability to check for uninitialized
> variables and/or their is no ability to define default values (e.g. a
> null) to variables of whatever type.
>

<- parts of other emails deleted, TD ->

In einer eMail vom 4/3/03 6:32:45 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Ina,


> The current problem is that there is no mean to check whether a variable
> is unitialized or not. If TTCN-3 would e.g. offer the ability to check
> this one would not need this lazy assignment. Then, one would be able to
> denote
>

I would be in favour of your universal null value, but this universal null
value is
then heavily overloaded, given that it is applicable to all types in an ATS.


>In TTCN-2 there are test case variables with the following
>characteristics: "A test suite may make use of a set of variables which
>are declared globally to the test suite but whose scope is defined to be
>local to the Test Case.

In TTCN-2, all TCVs (Test Case Variables) are globally visible, but only
have local
scope to the test case they are defined. In Concurrent TTCN-2, TCVs passed
as
actual parameters to a test step referenced in a CREATE statement will have
global scope to the given PTC in which it is created. You may in fact
instantiate
as many PTCs with these same variables, and all of them will be distinct,
according
to the standard. Note that for PCOs only one component is permitted to
reference
any given ATS PCO. TTCN-2 does not permit two different PTCs to use the same
PCO (this is verified statically, in the Test Component Configuration
Declarations
table ). The same thing with CPs except that each CP can only be referenced
in two
PTCs, which must respect the TCC declaration. I'm not exactly convinced that

textual substitution is required for PCOs and CPs, Call by Value would also
be
sufficient, and one can statically verify adherence to the TCC by traversing
the
TTCN-2 source code, so that run time problems are avoided.

>To be honest, this "fresh copy" is also a grey zone in TTCN-2. If
>"fresh" means initialized to their initial/default values and
>unitialized if no such value exist, we would have also no problem in the
>TTCN-3 case.

The intent of the word 'fresh copy' is that each PTC which is
created,receives
an independent set of TCVs which might be unbound, depending on whether they
were bound to a value at their point of declaration. That is, each TCV is
given the
value provided at its point of declaration in the Test Case Variable
Declarations
table.

>Taking this literally means that a created PTC needs to get the current
>values of test case variables from the MTC (only the MTC creates PTCs in
>TTCN-2).

Your first interpretation of the TTCN-2 standard is the correct one. The
above,
is not the intent of the TTCN-2 standard. The word fresh should be replace
by
clearer text, which does not permit the ambiguous interpretation which you
present in this message. :-).

>Now, a translator between TTCN-2 to TTCN-3 works structurally.

What do you mean by structurally? There is more to the translation than
structure.
You still have to maintain the TTCN-2 semantics within the TTCN-3 context,
and this
'problem' or hurdle, has been the source of problems for everyone developing
a
TTCN-2 to TTCN-3 translator. :-)

>In order to provide these fresh copies it has to pass the current TCV
>values into the test component and to bind it to the local TCVs of
>created test components. The MTC starts the test component behavior by
>parameterizing it with the TCV values. This behavior then binds at the
>beginning the local TCV (e.g. to be placed as variables in the test
>component type definition) to these current values - leading us to the
>case of x:=y - and apparently, such a value can still be
>undefined/unitialized, which causes problems as the lazy assignments are
>in a grey zone of TTCN-3 (not explicitly allowed and not explicitly
>forbidden) and/or as their is no ability to check for uninitialized
>variables and/or their is no ability to define default values (e.g. a
>null) to variables of whatever type.

Ah. Now I see what you mean. Well, this problem does not arise, since your
TCVs do not necessarilyneed to be defined globally, they can be defined
locally in each and every one of your components, since TCVs have local scope

to the test case, but then, at this point, this solution violates the
structural
consistency. That is the translated TTCN-3 code, does not at all resemble
the original TTCN-2 code. The key to solving this, is to identify which
variables
are unbound in the original TTCN-2 code, and not assign them in the TTCN-3
code.
At least them you won't get any run-time errors related to assignments using
unbound variables. Then again, if a TCV is used in an expression, and that
TCV
is unbound, you will still have problems. :-). Hummm.

As you indicate, if you use your second interpretation, than translation from
TTCN-2
to TTCN-3, becomes problematic especially when it comes to maintaining the
TTCN-2 semantics within the TTCN-3 context.


Having said all this, I'm still in favour or disallowing lazy assignment.

cheers,


Claude.






Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

In einer eMail vom 4/3/03 10:04:55 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Thomas,

We both have the same understanding of TCVs, their binding, and re-binding,
which is
in agreement with Ina's first hypothesis.

Fresh means 'new instances' bound to the initial value as specified (or not)
in the original
TCV Declarations proforma.



> The standard just mentions two ways when a test case variable is bound: At
> declaration, we are not talking about this here. Or in an assignment, we
> are not talking about this here either. The standard does not talk about
> binding a Test Case Variable on a PTC by binding the Test Case Variable on
> the MTC before the CREATE statement.
>
> Also, the standard requires in 11.8.3 to create a fresh copy of a test case
> variable for each test component. Not just a copy, but a fresh copy. I
> understand this as a new instance of the variable, but not as a copy of the
> test case variable on the MTC including its value. But I can be wrong here.
>
> I admit that my arguments do not rule out Ina's understanding. But at least
> I have serious doubts whether Ina's is the correct one. I would greatly
> appreciate it if somebody with more TTCN-2 expertise could help us to make
> this grey area more white.
>
>
Cheers,

Claude.


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

Hello all,

Just thought I'd put in a few comments on this from a TTCN-2 point of
view... My experience of TTCN-3 is pretty limited - I'm keeping half an eye
on this email list, but haven't had time to read the specs in detail, so
apologies if my comments aren't helpful from a TTCN-3 point of view...

This area of TTCN-2 is indeed very grey, and I'm afraid rather than making
it any whiter, I'm going to illustrate how it is even greyer than it appears
at first...

When we were writing the 3GPP conformance tests, we checked this clause in
the spec fairly carefully, because we were trying to decide if it was valid
to use a wildcard on the RHS of an assignment. e.g. ( tcv_A := * ). Based on
the core spec, it is very difficult to argue that this is invalid (and it
seems to be partially supported by some tools). Furthermore, it leads to all
sorts of wierd problems like 'What happens when I add one to tcv_A?????'

The temptation to use wildcards in variable is clear - For example I might
have a test step to initialise the variable with the appropriate value, and
then pass the variable as a parameter to a constraint (parlez vous TTCN-2?):

[ px_StrictChecking = TRUE ]
( tcv_FieldA := 3 )
[ px_StrictChecking = FALSE ]
( tcv_FieldA := ? )

Then I can pass this TCV into a constraint to be used as the value for
fieldA, and depending on the boolean PIXIT value px_StrictChecking, either
fieldA must have the value 3, or fieldA can have any value...

However, there are certainly other solutions to this problem that don't
require use of wildcards on the RHS, so the whole problem can be avoided...
If the core spec had been clear, we wouldn't have wasted time considering
the wildcard based approach...

So, in my experience, I think that allowing grey areas such as use /
reference of uninitialised variables causes more problems that it solves,
and I register my vote for making sure that the core specs are as white as
possible in the first place...

I hope this helps, have a great day!

Jeremy


>

---

Original Message

---

> From: Thomas Deiss [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> Sent: 03 April 2003 20:00
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: Assignment of uninitialized variables
>
>
> Hello all,
>
> as Ina has pointed out there is a grey area in TTCN-2. May I
> suggest that we first make this area less grey before
> argueing about TTCN-3 or even changing it based on a grey
> area in TTCN-2.
>
> For easier reference, the parts cited by Ina are from Clauses
> 11.8.3 and 4 from ISO/IEC 9646-3. I am using the 1998 version
> of the standard.
>
> Clause 11.8.4 defines when a test case variable is bound:
>
> "Initially Test Case Variables are unbound. They may become
> bound (or be re-bound) in the following contexts:
> a) at the point of declaration if an initial value is specified;
> b) when the Test Case appears on the left-hand side of an
> assignment statement (see 15.10.4).
> Once a Test Case Variable has been bound to a value, the Test
> Case Variable will retain the that value until either it is
> bound to a different value, or execution of the Test Case
> terminates - whichever occurs first. At termination of the
> Test Case, the Test Case Variable becomes re-bound to its
> initial value, if one is specified, otherewise it becomes unbound.
> If an unbound Test Case Variable is used in the right-hand
> side of an asssignment, then it is a test case error."
>
> The standard just mentions two ways when a test case variable
> is bound: At declaration, we are not talking about this here.
> Or in an assignment, we are not talking about this here
> either. The standard does not talk about binding a Test Case
> Variable on a PTC by binding the Test Case Variable on the
> MTC before the CREATE statement.
>
> Also, the standard requires in 11.8.3 to create a fresh copy
> of a test case variable for each test component. Not just a
> copy, but a fresh copy. I understand this as a new instance
> of the variable, but not as a copy of the test case variable
> on the MTC including its value. But I can be wrong here.
>
> I admit that my arguments do not rule out Ina's
> understanding. But at least I have serious doubts whether
> Ina's is the correct one. I would greatly appreciate it if
> somebody with more TTCN-2 expertise could help us to make
> this grey area more white.
>
> Best regards
>
> Thomas
>
> >

---

Original Message

---

> > From: ext Ina Schieferdecker
> > [This email address is being protected from spambots. You need JavaScript enabled to view it.]
> > Sent: Thursday, April 03, 2003 6:31 AM
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: Assignment of uninitialized variables
> >
>
> <- parts of other emails deleted, TD ->
>
> >
> > In TTCN-2 there are test case variables with the following
> > characteristics: "A test suite may make use of a set of
> > variables which
> > are declared globally to the test suite but whose scope is
> > defined to be
> > local to the Test Case. In concurrent TTCN, each test component,
> > including the MTC, receives a fresh copy of all Test Case
> > Variables when
> > it is created. ... In the CREATE construct, PCO identifiers and CP
> > identifiers are passed to a PTC by textual substitution, as
> > is usual in
> > the ATTACHment of Test Steps. All others parameters are
> > passed by value.
> > This is done to prevent side effects on variables which could
> > affect the
> > processing of other PTCs, causing unrepeatable results."
> >
> > To be honest, this "fresh copy" is also a grey zone in TTCN-2. If
> > "fresh" means initialized to their initial/default values and
> > unitialized if no such value exist, we would have also no
> > problem in the
> > TTCN-3 case. However, another part in TTCN-2 talks about
> "Once a Test
> > Case Variable has been bound to a value, the Test Case Variable will
> > retain that value until either it is bound to a different value, or
> > execution of the Test Case terminates - whichever occurs first. "
> >
> > Taking this literally means that a created PTC needs to get
> > the current
> > values of test case variables from the MTC (only the MTC
> > creates PTCs in
> > TTCN-2). Now, a translator between TTCN-2 to TTCN-3 works
> > structurally.
> > In order to provide these fresh copies it has to pass the
> current TCV
> > values into the test component and to bind it to the local TCVs of
> > created test components. The MTC starts the test component
> behavior by
> > parameterizing it with the TCV values. This behavior then
> binds at the
> > beginning the local TCV (e.g. to be placed as variables in the test
> > component type definition) to these current values -
> leading us to the
> > case of x:=y - and apparently, such a value can still be
> > undefined/unitialized, which causes problems as the lazy
> > assignments are
> > in a grey zone of TTCN-3 (not explicitly allowed and not explicitly
> > forbidden) and/or as their is no ability to check for uninitialized
> > variables and/or their is no ability to define default
> values (e.g. a
> > null) to variables of whatever type.
> >
>
> <- parts of other emails deleted, TD ->
>

---

This email message, together with any attachments, is for the exclusive and
confidential use of the addressee(s). If you have received this message in
error, please notify the sender by email immediately, then delete the
message and any copies. Any views or opinions presented herein are solely
those of the author and do not necessarily represent those of the Anritsu
group of companies.
Discover What's Possible - www.eu.anritsu.com

---

Hi Claude,

I simply sum up my answers at the top. All the discussion is about how
to preserve TTCN-2 semantics when mapping to TTCN-3. The question is for
that, what the TTCN-2 semantics is - and the discussion showed already
that the semantics of TCV - meaning the fresh copy - is a grey zone.
There is no right or wrong here - it is simply technically not defined.
We are arguing that it is a copy with the current values - you and
Thomas are saying that it is a copy with the initial values ... I see
that we can leave the discussion on trying to find the precise
definition of this in TTCN-2 as there isn't one. Even more, there does
not seem to be the status quo interpretation within the community ...
Having said that, we will simply make an option to the translation -
either with a real copy or with an initialized copy of TCVs.

Cheers, Ina.

Claude Desroches wrote:
> In einer eMail vom 4/3/03 6:32:45 AM W. Europe Daylight Time schreibt
> This email address is being protected from spambots. You need JavaScript enabled to view it.:
>
> Hi Ina,
>
>
>> The current problem is that there is no mean to check whether a variable
>> is unitialized or not. If TTCN-3 would e.g. offer the ability to check
>> this one would not need this lazy assignment. Then, one would be able to
>> denote
>
>
>
> I would be in favour of your universal null value, but this universal
> null value is
> then heavily overloaded, given that it is applicable to all types in an
> ATS.
>
> >In TTCN-2 there are test case variables with the following
> >characteristics: "A test suite may make use of a set of variables which
> >are declared globally to the test suite but whose scope is defined to be
> >local to the Test Case.
>
> In TTCN-2, all TCVs (Test Case Variables) are globally visible, but
> only have local
> scope to the test case they are defined. In Concurrent TTCN-2, TCVs
> passed as
> actual parameters to a test step referenced in a CREATE statement will have
> global scope to the given PTC in which it is created. You may in fact
> instantiate
> as many PTCs with these same variables, and all of them will be
> distinct, according
> to the standard. Note that for PCOs only one component is permitted to
> reference
> any given ATS PCO. TTCN-2 does not permit two different PTCs to use the
> same
> PCO (this is verified statically, in the Test Component Configuration
> Declarations
> table ). The same thing with CPs except that each CP can only be
> referenced in two
> PTCs, which must respect the TCC declaration. I'm not exactly convinced
> that
> textual substitution is required for PCOs and CPs, Call by Value would
> also be
> sufficient, and one can statically verify adherence to the TCC by
> traversing the
> TTCN-2 source code, so that run time problems are avoided.
>
> >To be honest, this "fresh copy" is also a grey zone in TTCN-2. If
> >"fresh" means initialized to their initial/default values and
> >unitialized if no such value exist, we would have also no problem in the
> >TTCN-3 case.
>
> The intent of the word 'fresh copy' is that each PTC which is
> created,receives
> an independent set of TCVs which might be unbound, depending on whether they
> were bound to a value at their point of declaration. That is, each TCV
> is given the
> value provided at its point of declaration in the Test Case Variable
> Declarations
> table.
>
> >Taking this literally means that a created PTC needs to get the current
> >values of test case variables from the MTC (only the MTC creates PTCs in
> >TTCN-2).
>
> Your first interpretation of the TTCN-2 standard is the correct one.
> The above,
> is not the intent of the TTCN-2 standard. The word fresh should be
> replace by
> clearer text, which does not permit the ambiguous interpretation which you
> present in this message. :-).
>
> >Now, a translator between TTCN-2 to TTCN-3 works structurally.
>
> What do you mean by structurally? There is more to the translation than
> structure.
> You still have to maintain the TTCN-2 semantics within the TTCN-3
> context, and this
> 'problem' or hurdle, has been the source of problems for everyone
> developing a
> TTCN-2 to TTCN-3 translator. :-)
>
> >In order to provide these fresh copies it has to pass the current TCV
> >values into the test component and to bind it to the local TCVs of
> >created test components. The MTC starts the test component behavior by
> >parameterizing it with the TCV values. This behavior then binds at the
> >beginning the local TCV (e.g. to be placed as variables in the test
> >component type definition) to these current values - leading us to the
> >case of x:=y - and apparently, such a value can still be
> >undefined/unitialized, which causes problems as the lazy assignments are
> >in a grey zone of TTCN-3 (not explicitly allowed and not explicitly
> >forbidden) and/or as their is no ability to check for uninitialized
> >variables and/or their is no ability to define default values (e.g. a
> >null) to variables of whatever type.
>
> Ah. Now I see what you mean. Well, this problem does not arise, since your
> TCVs do not necessarilyneed to be defined globally, they can be defined
> locally in each and every one of your components, since TCVs have local
> scope
> to the test case, but then, at this point, this solution violates the
> structural
> consistency. That is the translated TTCN-3 code, does not at all resemble
> the original TTCN-2 code. The key to solving this, is to identify which
> variables
> are unbound in the original TTCN-2 code, and not assign them in the
> TTCN-3 code.
> At least them you won't get any run-time errors related to assignments using
> unbound variables. Then again, if a TCV is used in an expression, and
> that TCV
> is unbound, you will still have problems. :-). Hummm.
>
> As you indicate, if you use your second interpretation, than translation
> from TTCN-2
> to TTCN-3, becomes problematic especially when it comes to maintaining the
> TTCN-2 semantics within the TTCN-3 context.
>
>
> Having said all this, I'm still in favour or disallowing lazy assignment.
>
> cheers,
>
>
> Claude.
>
>
>
>
>
>
> Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
> 685 Cedar Point Road phone: +1 705 533 23 94
> Penetanguishene, Ontario
> Canada
> L9M 1R3
>
> Solonplatz 3 phone: +49 30 9606 7986
> 13088 Berlin
> Germany


--

---

Ina Schieferdecker
Fraunhofer FOKUS email: This email address is being protected from spambots. You need JavaScript enabled to view it.
Kaiserin-Augusta-Allee 31 tel: ++49-30-3463-7241
D-10589 Berlin fax: ++49-30-3463-8241

---

In einer eMail vom 4/4/03 2:22:31 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:

Hi Jeremy,

I remember you asking me about the details regarding use of matching
mechanisms
in constraint references back in Augustof 2001 in TTCN-2. It is a grey area.
I have reviewed this time and again, and have had some discussion with
others on this specific issue.

My conclusions (and these may not necessarily be one hundred percent
correct),
are:

Wildcards/matching mechanisms can be used:
-directly in a receive constraint.
-directly in a send constraint (so long as they are overwritten by an
assignment
binding that particular parameter to a concrete value (not a matching
mechanism).
-as an actual parameter in a constraint reference
-as an actual parameter to a test step (should be used in a constraint
ref ).
-as an actual parameter to a Test Suite Operation or Test Suite
Operation Procedure
-To an invalid encoding operation don't know what use this would be, but
allowed.

So long as any actual parameter value (which happens to be a matching
mechanism)
is not assigned, or used in an expression, logical, relational, arithmetic or
other,
there should be no problem,

Things like the following don't make sense (c_X and c_Y are constraints
containing
possibly the same structure and possibly using the same matching mechanisms,
but
need not be assumed.

e.g. [ c_X = c_Y ]

If c_X and c_Y are structurally the same (of the same type, what are the
conditions which
make them equal to one another when wildcards are used? Are they the same if
and only if they use the same matching mechanisms for the same fields? or
are they in spite of this
different? (not defined by the standard).


> When we were writing the 3GPP conformance tests, we checked this clause in
> the spec fairly carefully, because we were trying to decide if it was valid
> to use a wildcard on the RHS of an assignment. e.g. ( tcv_A := * ). Based
> on
> the core spec, it is very difficult to argue that this is invalid (and it
> seems to be partially supported by some tools). Furthermore, it leads to
> all
> sorts of wierd problems like 'What happens when I add one to tcv_A?????'

The semantics of assigning a constraint which uses matching mechanisms to a
TCV
is not defined. Some tools allow this, others require that if a TCV is
assigned a constraint reference value, then all fields in the constraint need
to be bound to a value which is itself not a constraint reference containing
matching mechanisms (i.e. a constant, or if you like
what ASN.1 calls a value reference. :-).

Many have requested that tcv_A := c_XXX ( *, ? ) be made legal. There
might be
some advantages, but it opens up a BIG can of worms.



>
> The temptation to use wildcards in variable is clear - For example I might
> have a test step to initialise the variable with the appropriate value, and
> then pass the variable as a parameter to a constraint (parlez vous
> TTCN-2?):
>
> [ px_StrictChecking = TRUE ]
> ( tcv_FieldA := 3 )
> [ px_StrictChecking = FALSE ]
> ( tcv_FieldA := ? )
>
> Then I can pass this TCV into a constraint to be used as the value for
> fieldA, and depending on the boolean PIXIT value px_StrictChecking, either
> fieldA must have the value 3, or fieldA can have any value...

The cleaner approach is to have separate constraints for the need situations,

but there would likely be an explosion of constraints required to maintain
all
possible combinations and permutations.

The above approach you describe can help reduce the number of constraints
needed in an ATS.


>
> However, there are certainly other solutions to this problem that don't
> require use of wildcards on the RHS, so the whole problem can be avoided...

Yes,

> If the core spec had been clear, we wouldn't have wasted time considering
> the wildcard based approach...
>
> So, in my experience, I think that allowing grey areas such as use /
> reference of uninitialised variables causes more problems that it solves,
> and I register my vote for making sure that the core specs are as white as
> possible in the first place...

I've always been of the opinion that standards should be written in such a
way that
ambiguous interpretation of the text is not possible. Of course making the
BNF
normative, or the text normative, it does not matter, helps in the matter of
clarifying
things. Better yet, the standard is written in such a way that there are no
differences
between the text and the BNF. An unambiguous specification is of benefit to
all,
tool developers and ATS developers.



>
> I hope this helps, have a great day!

I will!!!

>
> Jeremy
>
>


Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany

In einer eMail vom 4/4/03 8:03:35 AM W. Europe Daylight Time schreibt
This email address is being protected from spambots. You need JavaScript enabled to view it.:


> Hi Claude,

Aren't ambiguous standards wonderful? :-).


>
> I simply sum up my answers at the top. All the discussion is about how
> to preserve TTCN-2 semantics when mapping to TTCN-3.

Yes, agreed, and sometimes it is not possible due to:
-ambiguities in the TTCN-2 standard.

-unsupported features in TTCN-3 (TTCN-2 STATIC variables for example).
How does
one implement static variables in a distributed environment, when the
language does
not support this (actually, STATIC variables were not used too much, so
it was
removed. I suspect that implementors were happy to see these go).

-dramatically different semantics between the two languages (e.g.
defaults, activate)
which require modification of the original ATS structure, or adding more
complexity
to compensate for missing or extensively different semantics.


The question is for
>
> that, what the TTCN-2 semantics is - and the discussion showed already
> that the semantics of TCV - meaning the fresh copy - is a grey zone.

Yes.


> There is no right or wrong here - it is simply technically not defined.
> We are arguing that it is a copy with the current values - you and
> Thomas are saying that it is a copy with the initial values ... I see
> that we can leave the discussion on trying to find the precise
> definition of this in TTCN-2 as there isn't one. Even more, there does
> not seem to be the status quo interpretation within the community ...
> Having said that, we will simply make an option to the translation -
> either with a real copy or with an initialized copy of TCVs.

Well, the choice of how to deal with these, should be left to the customer,
given that
there are two solutions. Both can be implemented, but both have there +'s
and -'s,
as always.


>
> Cheers, Ina.
>
>

cheers,


Claude.

Conformance Technologies Ltd. email: This email address is being protected from spambots. You need JavaScript enabled to view it.
685 Cedar Point Road phone: +1 705 533 23 94
Penetanguishene, Ontario
Canada
L9M 1R3

Solonplatz 3 phone: +49 30 9606 7986
13088 Berlin
Germany