Mariusz,

You are keen in engaging other people into a discussion. ;)

It is my belief that it is probably not the best idea to
compare TTCN-3 with low-level languages like C or even
[higher-level] C++. After all, TTCN-3 (much like its
predecessor TTCN-2) is largely an abstract language for
test specifications, and some areas in the current TTCN-3
specification are in my understanding intentionally left
open to allow future language extensions without breaking
the specification of the core language.

As of union in TTCN-3: it could be so that the "union"
construct and its properties have been adopted in TTCN-3
from other abstract languages like ASN.1 ("CHOICE") and
OMG IDL ("union"), so it should not be very much confusing
at least for those users who are familiar with ASN.1 and/or
IDL.

And, yes, in ASN.1 they have tags used e.g. by BER
(Basic Encoding Rules), so it should be allowed to have
fields of the same type in the same CHOICE construct.

NB: Do not confuse "UNION" in ASN.1 with "union" in TTCN-3.
The former is used to specify type constraints, not types
themselves, if I remember it correctly.

You might want to check the X.680 family of standards
referring to ASN.1 and various transfer syntax notations
described therein for further details.

It might be also instructive to check the specification
of the "union" construct in CORBA IDL (www.omg.org)
and its mapping to programming languages like C++ and Java.

Hope this helps,

Alexey Mednonogov,
Software Engineer

Open Environment Software Oy
www.openttcn.com/

DISCLAIMER: Opinions expressed herein do not necessarily
coincide with the opinions of Open Environment Software Oy,
although I would like to think we share some common views.


Mariusz Kupiec <This email address is being protected from spambots. You need JavaScript enabled to view it.> wrote:

> Hi,
>
> I have never used unions in TTCN and ASN.1, only in C language, in times
> where in a good fashion was to operate on registers. I am a little bit
> surprised with unions in TTCN-3 because they have some extra features in
> my opinion.
>
> Shortly:
> 1) In TTCN-2 there is no unions. Only word UNION appears as an ASN.1
> Reserved Word.
> 2) Function IS_CHOSEN is defined in TTCN-2 as:
>
> IS_CHOSEN(DataObjectReference) -> BOOLEAN
>
> The operation returns the BOOLEAN value TRUE if and only if the data
> object reference specifies the variant of the CHOICE type that is
> actually selected for a given data object. Otherwise the result is
> FALSE. The operation shall not be applied to data objects or fields of
> data objects other than those of ASN.1 type CHOICE. The argument of the
> operation shall have the format as defined in 15.10.2.
>
> EXAMPLE 15: Use of IS_CHOSEN:
> if received_PDU is of ASN.1 type
> CHOICE {p1 PDU_type1,
> p2
> PDU_type2,
> p3 PDU_type
> }
> then, the operation call
> IS_CHOSEN(received_PDU.p2)
> returns TRUE if the actual instance of received_PDU carries a PDU of the
> type PDU_type2.
>
> I am not familar with ASN.1 but I assume the CHOICE variants should
> be all of unique types. In this case the IS_CHOSEN operation easily /and
> in unique manner/ identifies the proper variant. Recognition of the
> variant in the actual instance is done by the unique type stored in
> instance and then associated reference is known.
> IS_CHOSEN operation do everything in reverse order, asks about
> reference, the associated type is then found and instance is checked for
> carrying specified type.
>
> 3) In TTCN-3 unions are defined as 'unions'. It is similar to C language
> and may be even misleading for those using C.
>
> Properties of unions in C:
> - unions are heterogenous collection of members,
>
> - union may hold different types of information at different
> times but at any time the union holds only a single type of
> information,
>
> - components of a union variable share storage,
>
> - the storage is the amount of storage required to store the
> largest member,
>
> - the storage allocated for the union will be interpreted
> differently depending on the union member being accessed,
>
> - storage for all members start at the same location /union
> members overwrite each other/,
>
> - programmer is responsible for asking for the kind of
> information that was stored there to avoid getting erroneous results.
>
>
> Example of use for C:
>
> struct FULLREGS {
>
> unsigned int ax;
>
> unsigned int bx;
>
> };
>
>
>
> struct FULLREGS {
>
> unsigned char al, ah;
>
> unsigned char bl, bh;
>
> };
>
>
>
> union REGS {
>
> struct FULLREGS x;
>
> struct HALFREGS h;
>
> };
>
>
>
> This example is specific because:
>
> - all union fields occupy the same memory size;
>
> - every time the REGS union can be read as full or half
> registers, which means implicit conversion of types occurs by using
> char-reading or word-reading operation.
>
>
>
>

---

>
>
>
> UNIONS IN TTCN-3
>
> What is different to previous definitions:
>
>
>
> 1. There is no requirement for union fields to be of different types /as
> I suppose was in ASN.1 CHOICE construct/. It is only stated in 6.3.5.0
> that "Union types are useful to model a structure which can take one of
> a finite number of known types.".
>
>
>
> See example from 15.3:
>
>
>
> type union UniD {
>
> integer d1,
>
> integer d2,
>
> };
>
>
>
> 2. Who keeps information about actually choosed variant and what kind of
> information is it?
>
>
>
> At first it is worth mentioning that TTCN-3 union fields are of not
> unique types as example 15.3 shows. That means information about type of
> the chosen field is not enough for the system to identify chosen field
> in unique manner and 'union' in TTCN-3 should have an extra feature.
> System should keep reference of the chosen field just for supporting
> 'ischosen' function.
>
>
>
> 3. Nothing is known about storage sharing mechanism, i.e. what is size
> of union structure, what happens when we try to access variant, which is
> not actually stored in union. Accessing the not chosen variant is in
> opposition to system data, which should keep reference to chosen field
> as it is shown in point 2.
>
>
>
> 4. Please look at Clause 15.3 Relational operators:
>
> "Two values of union types are equal if, and only if, in both values the
> types of these chosen fields are compatible and the actual values of the
> chosen fields equal."
>
>
>
> What does it mean:
>
> - there is not known if references of chosen fields should be
> identical,
>
> - there is nothing known about positions of the chosen fields inside
> unions /if they should be counterparts/,
>
> - types of chosen fields should be compatible,
>
> - actual values of the chosen fields are equal.
>
>
>
> Please look at union examples from 15.3:
>
>
>
> type union UniD {
>
> integer d1,
>
> integer d2,
>
> };
>
>
>
> type union UniE {
>
> integer e1,
>
> integer e2,
>
> };
>
>
>
> type union UniF {
>
> integer f1,
>
> integer f2,
>
> boolean f3,
>
> };
>
>
>
> const UniD conUniD1 := { d1:= 0 };
>
> const UniE conUniE1 := { e1:= 0 };
>
> const UniE conUniE2; := { e2:= 0 };
>
> const UniF conUniF1; := { f1:= 0 };
>
>
>
> // Then
>
>
>
> conUniD1 == conUniE1;
>
> // returns true
>
> conUniD1 == conUniE2;
>
> // returns false, as the chosen field e2 is not the counterpart
> of the field d1 of UniD1
>
> conUniD1 == conUniF1;
>
> // returns false, as the effective value structures of UniD1 and
> UniF are not compatible
>
>
>
>
>
> What I think here is that all comparisons should return value 'true'.
>
> The second operation should produce TRUE because types and values of
> chosen fields are equal. Union was initialized in both cases with
> integer type of 0 value. The counterpart of fields is not applicable to
> unions here. The third example says about 'effective value structures'
> incompatibility but I do not think it is true. For 'effective value'
> only chosen field should be taken and actual values.
>
>
>
> 5. Clause 6.0 General
>
> "The special data type anytype is defined as the union of all known
> types within a module."
>
>
>
> Example from 6.4 anytype:
>
>
>
> var anytype MyVarOne, MyVarTwo;
>
> var integer MyVarThree;
>
>
>
> MyVarOne.integer := 34;
>
> MyVarTwo := {integer := MyVarOne + 1};
>
>
>
> MyVarThree := MyVarOne ц≈ 12;
>
>
>
>
> I have bad feeling that 'anytype' union may be accessed in two different
> ways:
>
> a) using field identifier 'integer', which is required for writing to
> field,
>
> b) using or not not using identifier as in case of read access to
> MyVarOne:
>
> 'MyVarThree := MyVarOne ц≈ 12;'
>
> MyVarOne is accessed without field identifier.
>
> Is it an error or it comes from knowledge that only valid value stored
> in antype is 'integer' type and after the write operation to chosen
> field this field is chosen until next write operation???
>
> This suggest that we do not need field notation for reading from union,
> only for writing to field.
>
>
>
> 6. The power of 'union' in TTCN-3 is doubtful. It has no properties of
> ASN.1 CHOICE /unique types/, neither C 'union' properties, it is
> doubtful if test suite writer can read other fields without dynamic
> error, can convert values implicitly as in example with registers /C
> language/ and also system should keep not only chosen type but
> also/rather chosen reference and update it after write operations to
> union fields.
>
>
>
> Last question may be anticipated.
>
> What is a benefit ... ?
>
>
>
>
>
> BR,
>
> Mariusz Kupiec
>
>
>
>
>
> BTW: There are also other notes to union description but maybe I do not
> know the language well.
>
>
>
>
> - the sentence from 6.3.5.0 "Only one of the specified fields will ever
> be present in an actual union value" is hard to understand for me, maybe
> 'all of specified fields may be used to reference union value but only
> one field at 'any/a given' time', why to construct structured variable,
> which always uses one field only?
>
>
> - next sentence is not precise "Union types are useful to model a
> structure which can take one of a finite number of known types", since
> e.g. we want in union different fields of common type to store
> temperature as Fahrenheight of Celsius degrees, that is not only 'types'
> differ union fields but also different representations for the same
> types?
>
> /collection of overlapped representations of objects of different
> types/
>
> - example in 6.3.5.0 and the comments should be extended since 'Note,
> this notation makes the given field to be the chosen one' suggests as
> the choice was done forever, not only for the current reading
> operation.
>
>
>

Hi Alexey,

Thank you very much for your explanation, especially for ASN.1, IDL and open
language extensions. There is no discussion on my lack of knowledge in ASN.1
and IDL, it is a fact.
Regarding TTCN language, it is specialized, high-level language but TTCN-3
changes not only look but also extends behaviour of TTCN-2. Many ideas are
imported form C, Pascal, Java or are just similar to used in these
languages.
It does not cost a much to ask a question and until at least one of
questions is valid I do not feel sorry for generating too much traffic on
the list.

And yes, I regard the discussion on examples from 15.3 open :-)

Current boolean values of expressions:
conUniD1 == conUniE1;
conUniD1 == conUniE2;
conUniD1 == conUniF1;

are:
a) true, false, false /by spec./
b) false, false, false /by Jacob/
c) true, true, true /be me/

Also in the comments instead of 'UniD1' should be either used 'UniD' /if
talking only about defined union structures/ or conUniD1 /if talking about
declared and initialized union structures/:

conUniD1 == conUniE2;
// returns false, as the chosen field e2 is not the counterpart of the field
d1 of UniD1
conUniD1 == conUniF1;

// returns false, as the effective value structures of UniD1 and UniF are
not compatible

BR,
Mariusz Kupiec

---

Original Message

---

From: "Alexey Mednonogov" <This email address is being protected from spambots. You need JavaScript enabled to view it.>
To: <This email address is being protected from spambots. You need JavaScript enabled to view it.>
Sent: Sunday, January 19, 2003 3:30 PM
Subject: Re: Unions in TTCN-3


Mariusz,

You are keen in engaging other people into a discussion. ;)

It is my belief that it is probably not the best idea to
compare TTCN-3 with low-level languages like C or even
[higher-level] C++. After all, TTCN-3 (much like its
predecessor TTCN-2) is largely an abstract language for
test specifications, and some areas in the current TTCN-3
specification are in my understanding intentionally left
open to allow future language extensions without breaking
the specification of the core language.

As of union in TTCN-3: it could be so that the "union"
construct and its properties have been adopted in TTCN-3
from other abstract languages like ASN.1 ("CHOICE") and
OMG IDL ("union"), so it should not be very much confusing
at least for those users who are familiar with ASN.1 and/or
IDL.

And, yes, in ASN.1 they have tags used e.g. by BER
(Basic Encoding Rules), so it should be allowed to have
fields of the same type in the same CHOICE construct.

NB: Do not confuse "UNION" in ASN.1 with "union" in TTCN-3.
The former is used to specify type constraints, not types
themselves, if I remember it correctly.

You might want to check the X.680 family of standards
referring to ASN.1 and various transfer syntax notations
described therein for further details.

It might be also instructive to check the specification
of the "union" construct in CORBA IDL (www.omg.org)
and its mapping to programming languages like C++ and Java.

Hope this helps,

Alexey Mednonogov,
Software Engineer

Open Environment Software Oy
www.openttcn.com/

DISCLAIMER: Opinions expressed herein do not necessarily
coincide with the opinions of Open Environment Software Oy,
although I would like to think we share some common views.

---

Poczta nowych mozliwosci >>> link.interia.pl/f16bc