Hello

The TRI part of the TTCN-3 standard specifies abstract TriMessage
type, which is also used in the TCI interface. TriMessage is defined
as BinaryString in the C mapping of the interfaces:

typedef struct BinaryString
{
unsigned char* data;
long int bits;
void* aux;
} BinaryString;

The TRI standard states that

NOTE 3: The aux field is for future
extensibility of TRI
functionality.

I would like to hear a clarification to this whether the note means

A)
Aux field is meant for the people who specify the TTCN-3 language
and interfaces, to extend the TRI functionality if required. End
user (adapter implementor, codec implementor) should not take this
field into own use.

or

B)
Aux field can be freely used by the adapter implementor to extend
the functionality of the TRI and TCI interfaces to the extent
allowed by the used tool.

The Aux field is also present in the C representation of other types
(not all).

Java mapping of the types does not contain a method for setting or
getting Aux value/object.

I have a feeling that A) is correct.

Br
Antti

Hello Antti,

I shall agree with your opinion that A) is more
correct, although my view is not grounded on any
clause in the standard, but A) option is probably
implied.

In fact, to make "aux" field work and be usable for
future extensions, it would have made sense to require
to set it to 0 by all current implementations. In the
absence of such requirement laid down in the current
version of the spec which does not use "aux", this
field would be difficult to use in the next version of
the spec, because if you allocate BinaryString on the
C function call stack as you normally do when you
declare a local automatic variable in C, then aux
field may contain any sort of garbage I guess
(function call stack is not automatically cleared with
zeros). Therefore, a hypothetical next version of the
library compliant with a hypothetical next version of
the spec that uses "aux" will have hard times to
decide whether this is a valid pointer or some garbage
reference, in case you link newer library against
existing user code. Otherwise, migration to the newer
version might require fixing the user code which is
never a nice thing to do.

Regards,
Alexey Mednonogov
OpenTTCN Oy

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

> Hello
>
> The TRI part of the TTCN-3 standard specifies
> abstract TriMessage
> type, which is also used in the TCI interface.
> TriMessage is defined
> as BinaryString in the C mapping of the interfaces:
>
> typedef struct BinaryString
> {
> unsigned char* data;
> long int bits;
> void* aux;
> } BinaryString;
>
> The TRI standard states that
>
> NOTE 3: The aux field is for future
> extensibility of TRI
> functionality.
>
> I would like to hear a clarification to this whether
> the note means
>
> A)
> Aux field is meant for the people who specify the
> TTCN-3 language
> and interfaces, to extend the TRI functionality
> if required. End
> user (adapter implementor, codec implementor)
> should not take this
> field into own use.
>
> or
>
> B)
> Aux field can be freely used by the adapter
> implementor to extend
> the functionality of the TRI and TCI interfaces
> to the extent
> allowed by the used tool.
>
> The Aux field is also present in the C
> representation of other types
> (not all).
>
> Java mapping of the types does not contain a method
> for setting or
> getting Aux value/object.
>
> I have a feeling that A) is correct.
>
> Br
> Antti
>

Hi all,

regarding the use of the aux field.
If develoeprs use the aux field they have to deal with the consequences of standard updates.
It is as simple as that.

When I have been implementing codecs I found it very useful to have an extra information element in the TriMessage type which stores the current bit position that a message has successfully decoded up to. So in my TRI data type handling I have handled allocation and deallocation of that aux field and have found it very useful to simplify information management in my decoder implementations.

Technically my next step could be to file a CR asking for a new field. But for the time being I am happy with the solution as is. Of course I will have to change my TRI implementation should the type definition be ever extended or changed. But I believe that this overhead is easily managable.

Sad to hear that the Java mappings do not allow access of such fields. I have been however implementing in C.
Again I found it useful in this B) type case as well.

Moikka,
stephan

>

---

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 ext Alexey Mednonogov
> Sent: 12 August, 2005 11:06
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: aux-field in the C-lang mapping of the standard
>
>
> Hello Antti,
>
> I shall agree with your opinion that A) is more
> correct, although my view is not grounded on any
> clause in the standard, but A) option is probably
> implied.
>
> In fact, to make "aux" field work and be usable for
> future extensions, it would have made sense to require
> to set it to 0 by all current implementations. In the
> absence of such requirement laid down in the current
> version of the spec which does not use "aux", this
> field would be difficult to use in the next version of
> the spec, because if you allocate BinaryString on the
> C function call stack as you normally do when you
> declare a local automatic variable in C, then aux
> field may contain any sort of garbage I guess
> (function call stack is not automatically cleared with
> zeros). Therefore, a hypothetical next version of the
> library compliant with a hypothetical next version of
> the spec that uses "aux" will have hard times to
> decide whether this is a valid pointer or some garbage
> reference, in case you link newer library against
> existing user code. Otherwise, migration to the newer
> version might require fixing the user code which is
> never a nice thing to do.
>
> Regards,
> Alexey Mednonogov
> OpenTTCN Oy
>
> --- Antti Hyrkkanen <This email address is being protected from spambots. You need JavaScript enabled to view it.>
> wrote:
>
> > Hello
> >
> > The TRI part of the TTCN-3 standard specifies
> > abstract TriMessage
> > type, which is also used in the TCI interface.
> > TriMessage is defined
> > as BinaryString in the C mapping of the interfaces:
> >
> > typedef struct BinaryString
> > {
> > unsigned char* data;
> > long int bits;
> > void* aux;
> > } BinaryString;
> >
> > The TRI standard states that
> >
> > NOTE 3: The aux field is for future
> > extensibility of TRI
> > functionality.
> >
> > I would like to hear a clarification to this whether
> > the note means
> >
> > A)
> > Aux field is meant for the people who specify the
> > TTCN-3 language
> > and interfaces, to extend the TRI functionality
> > if required. End
> > user (adapter implementor, codec implementor)
> > should not take this
> > field into own use.
> >
> > or
> >
> > B)
> > Aux field can be freely used by the adapter
> > implementor to extend
> > the functionality of the TRI and TCI interfaces
> > to the extent
> > allowed by the used tool.
> >
> > The Aux field is also present in the C
> > representation of other types
> > (not all).
> >
> > Java mapping of the types does not contain a method
> > for setting or
> > getting Aux value/object.
> >
> > I have a feeling that A) is correct.
> >
> > Br
> > Antti
> >
>

Hi Stephan

> Hi all,

> regarding the use of the aux field.
> If develoeprs use the aux field they have to deal with the
> consequences of standard updates. It is as simple as that.

I think it could be more clearly stated that the field is not reserved
developers, so they know not to build their fortune on having a fancy
solution relying on it :). I had to compare the C part of the
standard with the Java part and do some reasoning before deciding
not to use the aux field for own purposes.

The following fancy solution depends a lot on the used
tool:

When the SA receives a message from the SUT, one can load information
about the protocol with which the message was received. If it was
receive from TCP port 80, I could say via the aux field that the
message is most likely a PDU of HTTP, if I get it from port 21, it is
PDU of FTP.

If my SA sets aux to point to that protocol information, this protocol
information possibly is present to my decoder also, and the decoder
can use it with the addition of the decoding hypothesis to determine
what the received data represents. This requires that the used tool
does not change the aux field value, and that the aux field value in
TriMessage in TriEnqueue*() operation ends up to the aux field of the
TriMessage of TciDecode() operation. This also requres that the CD
and SA are in the same address space since aux is a pointer.

A safer approach would be to prefix the received message with the
protocol information, if the decoders want to use it. Maybe it
was useful, if there was an extra field that could be used
to pass protocol information separately from the received data,
and this field was of lets say type Binarystring, so its value
could be copied, when the TriMessage is copied.

Antti

>

---

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 ext Stephan Schulz
> Sent: 22. elokuuta 2005 10:56
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: aux-field in the C-lang mapping of the standard
>
>
> Hi all,
>
> regarding the use of the aux field.
> If develoeprs use the aux field they have to deal with the
> consequences of standard updates.
> It is as simple as that.
>
> When I have been implementing codecs I found it very useful to have
> an extra information element in the TriMessage type which stores the
> current bit position that a message has successfully decoded up to.
> So in my TRI data type handling I have handled allocation and
> deallocation of that aux field and have found it very useful to
> simplify information management in my decoder implementations.
>
> Technically my next step could be to file a CR asking for a new
> field. But for the time being I am happy with the solution as is. Of
> course I will have to change my TRI implementation should the type
> definition be ever extended or changed. But I believe that this
> overhead is easily managable.
>
> Sad to hear that the Java mappings do not allow access of such
> fields. I have been however implementing in C.
> Again I found it useful in this B) type case as well.
>
> Moikka,
> stephan

Hi antti,

ok - let me just clarify. My example did not involve sending aux field values across TRI or TCI. I only used it
locally in the decoder, i.e., _within_ the CD entity. I mean that I allocated the field in the beginning of my tciDecode operation .. and then dealloacted it before returning from it.

But now I see finally your point in how this aux field can be misleading.

Moikka,
stephan


>

---

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 ext Antti Hyrkkanen
> Sent: 22 August, 2005 12:07
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: aux-field in the C-lang mapping of the standard
>
>
> Hi Stephan
>
> > Hi all,
>
> > regarding the use of the aux field.
> > If develoeprs use the aux field they have to deal with the
> > consequences of standard updates. It is as simple as that.
>
> I think it could be more clearly stated that the field is not
> reserved
> developers, so they know not to build their fortune on having a fancy
> solution relying on it :). I had to compare the C part of the
> standard with the Java part and do some reasoning before deciding
> not to use the aux field for own purposes.
>
> The following fancy solution depends a lot on the used
> tool:
>
> When the SA receives a message from the SUT, one can load information
> about the protocol with which the message was received. If it was
> receive from TCP port 80, I could say via the aux field that the
> message is most likely a PDU of HTTP, if I get it from port 21, it is
> PDU of FTP.
>
> If my SA sets aux to point to that protocol information, this
> protocol
> information possibly is present to my decoder also, and the decoder
> can use it with the addition of the decoding hypothesis to determine
> what the received data represents. This requires that the used tool
> does not change the aux field value, and that the aux field value in
> TriMessage in TriEnqueue*() operation ends up to the aux field of the
> TriMessage of TciDecode() operation. This also requres that the CD
> and SA are in the same address space since aux is a pointer.
>
> A safer approach would be to prefix the received message with the
> protocol information, if the decoders want to use it. Maybe it
> was useful, if there was an extra field that could be used
> to pass protocol information separately from the received data,
> and this field was of lets say type Binarystring, so its value
> could be copied, when the TriMessage is copied.
>
> Antti
>
> >

---

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 ext Stephan Schulz
> > Sent: 22. elokuuta 2005 10:56
> > To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> > Subject: Re: FW: aux-field in the C-lang mapping of the standard
> >
> >
> > Hi all,
> >
> > regarding the use of the aux field.
> > If develoeprs use the aux field they have to deal with the
> > consequences of standard updates.
> > It is as simple as that.
> >
> > When I have been implementing codecs I found it very useful to have
> > an extra information element in the TriMessage type which
> stores the
> > current bit position that a message has successfully decoded up to.
> > So in my TRI data type handling I have handled allocation and
> > deallocation of that aux field and have found it very useful to
> > simplify information management in my decoder implementations.
> >
> > Technically my next step could be to file a CR asking for a new
> > field. But for the time being I am happy with the solution
> as is. Of
> > course I will have to change my TRI implementation should the type
> > definition be ever extended or changed. But I believe that this
> > overhead is easily managable.
> >
> > Sad to hear that the Java mappings do not allow access of such
> > fields. I have been however implementing in C.
> > Again I found it useful in this B) type case as well.
> >
> > Moikka,
> > stephan
>

Hi Stephan

>

---

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 ext Stephan Schulz
> Sent: 22. elokuuta 2005 12:26
> To: This email address is being protected from spambots. You need JavaScript enabled to view it.
> Subject: Re: FW: aux-field in the C-lang mapping of the standard
>
>
> Hi antti,
>
> ok - let me just clarify. My example did not involve sending aux
> field values across TRI or TCI. I only used it
> locally in the decoder, i.e., _within_ the CD entity. I mean that I
> allocated the field in the beginning of my tciDecode operation ..
> and then dealloacted it before returning from it.

Yep, your use of the field is much more safer since the value
stays within your hands and is not passed to the TE. Mine was
playing with fire, but it does work with tool x.

>
> But now I see finally your point in how this aux field can be misleading.

Great :)

Antti