Home » Eclipse Projects » Eclipse Titan » decvalue for RFC4826 XML fails (Example code for demostrating an issue with decvalue for simple XML)
| | | | |
Re: decvalue for RFC4826 XML fails [message #1829162 is a reply to message #1829126] |
Fri, 26 June 2020 07:42 |
|
Hi Olaf,
yes , we have received a bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=564585
from one of your colleagues maybe.
here's my view on the matter:
Indeed, the standard (par 6.3.1)
EXAMPLE 4: Compatibility of character and universal character strings:
//Given
type charstring MyChar length (1);
...
var MyChar v_myCharacter;
var charstring v_myCharString;
var universal charstring v_myUnivCharString;
// Given
v_myCharString := "abcd";
// Then
v_myUnivCharString := v_myCharString
//is valid as charstring and universal charstring are compatible
v_myCharacter := v_myUnivCharString [1]; //example 4.1
// is valid as the r.h.s. notation addresses a single element of the string,
// containing a character compatible with charstring
// Given
v_myUnivCharString := "bet" & char ( 0, 0, 1, 113);
// Then
v_myCharString := v_myUnivCharString; //example 4.2
// is invalid as v_myUnivCharString contains a character not in ISO 646.
// Given
var charstring v_myCharacterArray [5] := {"A", "B", "C", "D", "E"}
// Then
v_myCharString := v_myCharacterArray[1];
// is valid and assigns the value "B" to v_myCharString;
says that a charactestring variable can take it's value from a universal charactestring (or a substring of a universal charactestring)
only if all its' characters are from ISO 646.
Which kind of stands to reason, considering that the character space of universal characters is far larger than that of ISO 646 characters.
The examples above can be decided at compilation time, as the values of the variables are initialized. Nonetheless,
Titan throws error both at example 4.1 which is supposed to be valid and at
example 4.2 which is obvously invalid as we are trying to squeeze non-ISO 646 characters into a charactestring.
The example you have quoted
function f_StringTest(universal charstring p_UCharString) return charstring
{
var charstring v_CharString := p_UCharString;
return v_CharString;
}
cannot be decided at compile time, as p_UCharString is not initialized;
I'd say this is a bit of a grayzone in the standard. However, if we extend the logic of example 4 in par.6.3.1,
we can state that the assignment in the function should be considered valid if p_UCharString consists of ISO 646 characters,
and invalid if at least one of the characters is non-ISO 646. This means that the assignment should lead to an error in invalid cases.
Technically this is possible, the validity can be decided during execution, as when the function is called, p_UCharString will be known.
(As this check will take a toll on runtime performance,
it should be implemented in Titan function test runtime only , not in the performance runtime).
Now, notwithstanding the standard, here comes my personal opinion:
-calling the above function is unsafe (terminates in error) unless we are certain at the moment of invokation that p_UCharString
contains only ISO 646 characters; which means it will most likely terminate in error, as the function cannot return a value.
However, in most of the scenarios the function invokation will terminate in error, unless we put some safeguards around the assignment.
On the other hand if we can safely state that p_UCharString is practically a characterstring,
then there was no point in using a universal charactestring in the first place.
The quoted part of the standard in this reference appears to be not very well thought through, as it opens the door
to an unsafe programming practice.
I don't remember encountering and I also fail to see the usefulness of a situation where a direct assigmment of a characterstring value
should originate in a universal charactestring. Could you please let me know in regard of which practical situation this question
was raised?
BTW, Titan has a non-standard function to make this kind of assignment safe, namely the built-in unichar2char function;
same can be achieved with unichar2oct/oct2char or oct2str from the standard.
In summary, arguably Titan does not align with the standard in this respect, however the standard appears to be flawed at this point.
Please let me know your opinion on the above.
Best regards
Elemer
|
|
| |
Re: decvalue for RFC4826 XML fails [message #1829834 is a reply to message #1829167] |
Sun, 12 July 2020 12:24 |
|
Hi Olaf,
after some deliberation, we have amended the compiler as below:
-the default behavior is unchanged, a compiler error is thrown when a universal charstring value is assigned to a charstring:
char2uni.ttcn:12.36-48: error: Type mismatch: a value of type `charstring' was expected instead of `universal charstring'
-when using compiler option -h
-h: allow unsafe universal charstring to charstring conversion
assignment of universal charstring to charstring is permitted;
if universal charstring consists of ISO 646 chareters only, this will lead to a valid result,
else a DTE is thrown:
char2uni.ttcn:12 Dynamic test case error: Non-ASCII characters cannot be used to initialize a charstring, invalid character char(0, 0, 1, 113) at index 3.
By using a compiler option, which requires an affirmation from the user, accidental unsafe usage of unichar 2 char assignment is prevented.
This seemed to be a reasonable compromise between standard requirements and practical considerations.
Best regards
Elemer
|
|
| | |
Goto Forum:
Current Time: Sat Oct 12 14:49:54 GMT 2024
Powered by FUDForum. Page generated in 0.05119 seconds
|