Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1

TOPIC: Decoding enumerated types

Decoding enumerated types 11 Dec 2003 10:50 #6603

Hi all,

Suppose I have a message type that contains an enumerated type, how should an
ETS handle messages that doesn't comply with the enumerated type? For instance,
in the example below what should happen if the message received is {2, 7} (7 is
not allowed according to the definition of the enumeration) -- should a test
case error be the result?

type enumerated MyEnum
{
DONALD (3),
DUCK (8)
}

type record MyMessage
{
integer param1,
MyEnum param2
}

// :
// :

a_port.receive( MyMessage: {?, ?} )


Maybe enumerated types should be avoided in (received) messages ...


Best regards,

Stefan Karlsson
The administrator has disabled public write access.

Decoding enumerated types 11 Dec 2003 11:06 #6604

ext Stefan Karlsson wrote:

>Hi all,
>
>Suppose I have a message type that contains an enumerated type, how
>should an ETS handle messages that doesn't comply with the enumerated
>type? For instance, in the example below what should happen if the
>message received is {2, 7} (7 is not allowed according to the
>definition of the enumeration) -- should a test case error be the result?
>
>
The numbers assigned to the enumeration literals in the definition do not
necessarily need to have anything to do with their particular encoding. There
are simply a hint to the TTCN-3 system how these values should be ordered. This
is different to ASN.1 where, I think, the assigned numbers are to be used in the
encoding of these values, too.

>type enumerated MyEnum
>{
> DONALD (3),
> DUCK (8)
>}
>
>

This does not say much more that DONALD < DUCK.

What happens once codecs come into play. Well, of course this depends on how you
want to encode these values. If you choose a textual encoding, they might be
encoded as

DONALD -> "DONALD", DUCK -> "DUCK"

If you are in a festive mode, you might as well choose to encode them as

DONALD -> "jingle bells, jingle bells", DUCK -> "merry christmas every one!"

Or, if you are into numerical encodings, you may choose to encode them as:

DONALD -> 3, DUCK -> 8

but also

DONALD -> 314, DUCK -> 279

would be a 'legal' encoding.

Now what happens when you receive a value that does not match your specific
chosen encoding [which is probably what you had in mind with you question], that
is simply a 'decoding error', which means that your decoder should report that
the value could not be decoded as the expected type. This is not necessarily a
test case error, but will rather cause the receive statement to fail to match.
If no default are active and no guard timer exists, that means that you get a
deadlock of the receive statement, which _is_ a test case error.

BR

Stephan Tobies

--
Stephan Tobies Sr. Research Engineer, Nokia Research Center
~ Mobile Networks Lab, Protocol Engineering Group
E-Mail: This email address is being protected from spambots. You need JavaScript enabled to view it.
Work Phone: +49-234-9842262
Mobile: +49-163-9842405
Fax: +49-234-9843491
Address: NRC Bochum, Meesmannstr. 103, 44807 Bochum, Germany
The administrator has disabled public write access.
  • Page:
  • 1

FacebookTwitterGoogle BookmarksRedditNewsvineTechnoratiLinkedin