Hi Claude,
> The formal parameter identifiers value and length are ILLEGAL.
> These are TTCN-3 reserved words. These need to be changed.
> I suspect that this goes for all other predefined operations.
>
> See table A.3 of ES201 873-1.
Yes, I completely agree.
Even, when in the definitions they are not bolded but going to other editor, where text attributes may be lost, confusion may arise.
This also applies to searching through the standard for e.g. whole keyword 'value' and its use in definitions.
"The number of hexadecimal digits provided shall be multiples of 2 since one octet is composed of two hexadecimal digits."
Does it mean that octetstring length is measured in hexadecimal digits, not in octets?
I have expected that length is measured in octets according Clause C.13 and that following description should be changed from:
> I can see where the confusion might arise. The first sentence you highlight above is
> to emphasize the fact that an octet = 2 hex digits and thus an even number of hex
> digits should be returned.
> I assume that length is given in octets and not in hex digits.
That is my fault. "The number of hexadecimal digits provided" means returned octetstring provided by function.
The right sentence which suggests length given in hex digits is this one:
"A test case error shall occur if the value is negative or if the resulting hexstring contains more hexadecimal digits than specified in the length parameter."
"If the conversion yields a value with fewer hexadecimal digits than specified in the length parameter, then the hexstring shall be padded on the left with zeros. A test case error shall occur if the value is negative or if the resulting hexstring contains more hexadecimal digits than specified in the length parameter."
> I don't agree. The wording should avoid reference to the hextstring type, since this is
> an octetstring conversion. Further, the use of the word 'value' leads to confusion, as
> it is unclear whether it refers to the return value which is the octetstring, or the in
> parameter value.
> As an aside, there are two glaring errors in the prototype for all the predefined functions
> As an aside, given your changed definition, what happens if I do the following
> int2octetstring( 15, 1) // 2nd par is given as # of octets
> result = '0F'O //padding of 1 0 to the left of F occurs.
> // this is needed as no assumption can be made on the
> // alignment of internal storage...
> by your definition, for the correct result to occur, the 2nd parameter would need to be
> in hexdigits,
> int2octetstring(15,2), I would then assume that 2 is the number of octets and not the
> number of hexdigits.
If you don't agree then you agree with me :-)
The above is from specification, not mine :-)
to
"If the conversion yields a value with fewer OCTETS than specified in the length parameter, then the OCTETstring shall be padded on the left with zeros. A test case error shall occur if the value is negative or if the resulting OCTETstring contains more OCTETS than specified in the length parameter."
BR,
> Better, however referene to value is unclear. Is it the return value, or the input parameter.
Yes, description may be a little bit extended.
> Cheers,
> Claude.
Cheers,
Mariusz