Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Eclipse Titan » decvalue for RFC4826 XML fails (Example code for demostrating an issue with decvalue for simple XML)
decvalue for RFC4826 XML fails [message #1828510] Thu, 11 June 2020 07:47 Go to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 80
Registered: November 2018
Member
Hi Titan- XML experts,

I think there is a bug in decvalue when decoding simple RFC 4826 XML data .


  /*
   * Test decvalue for XML type  ResourceLists_Type
   */
  function f_test_decvalue_ResourceLists() {

    const charstring tsc_ResourceLists_1 := "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\n" &
  "<resource-lists xmlns=\"urn:ietf:params:xml:ns:resource-lists\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">\n" &
"   <list>\n" &
"      <entry uri=\"org.3gpp.mcptt.ue-config/users/urn:uuid:e740ed78-ca4f-4435-8006-a4d97925a684\"/>\n" &
"   </list>\n" &
"</resource-lists>\n";

    var ResourceLists_Type v_DecodedResourceLists;
    var bitstring v_BitStr;

    
    v_BitStr := oct2bit(char2oct( tsc_ResourceLists_1));
    if (decvalue(v_BitStr, v_DecodedResourceLists) != 0) {
        log(v_DecodedResourceLists);
    	setverdict(fail);
      } else {
	setverdict(pass);
      }    
    }




The good news is that only the return value is incorrect, the decoded value is correct :-)

Attached my sub-project.


Regards,
Olaf
Re: decvalue for RFC4826 XML fails [message #1828512 is a reply to message #1828510] Thu, 11 June 2020 07:59 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Olaf,

I have opened a tracker in Bugzilla:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=564193


Best regards
Elemer
Re: decvalue for RFC4826 XML fails [message #1829113 is a reply to message #1828512] Thu, 25 June 2020 11:04 Go to previous messageGo to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 80
Registered: November 2018
Member
Hi Elemer,

I found the problem: We use decvalue on an alias type definition, not the type generated by xsd2ttcn, which is Resource_list. The alias is:


 type Resource_lists ResourceLists_Type; 


Using the Resource_list as the type to be decoded decvalue works correctly! So, I don't know if this can be considered a bug of decvalue.

Regards,
Olaf
Re: decvalue for RFC4826 XML fails [message #1829116 is a reply to message #1829113] Thu, 25 June 2020 11:24 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Olaf,
Thank you for the clarification; we will examine
the issue.


BR

Elemer
Re: decvalue for RFC4826 XML fails [message #1829126 is a reply to message #1829116] Thu, 25 June 2020 14:12 Go to previous messageGo to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 80
Registered: November 2018
Member
A question to you, Elemer, which is not quite related to this issue, but which we have been discussing internally in ETSI / MCC TF 160:

See follwoing code:
  function f_StringTest(universal charstring p_UCharString) return charstring
  {
    var charstring v_CharString := p_UCharString;  
    return v_CharString;
  }


In my view this is illegal code (the strings have different encoding), and Titan considers it as illegal code. But some colleagues think that the TTCN specification allows such an assignment.

Do you have a view on this?

Regards,
Olaf
Re: decvalue for RFC4826 XML fails [message #1829162 is a reply to message #1829126] Fri, 26 June 2020 07:42 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
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 #1829167 is a reply to message #1829162] Fri, 26 June 2020 09:17 Go to previous messageGo to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 80
Registered: November 2018
Member
Thanks, Elemer. I fully agree!
Also my personal opinion: It would be unsafe to allow such an assignment, in particular when engineers coding test cases at a high level are not involved and don't care about the low level details. And then people like myself have the pain of debugging run time errors, the pain of discussions and writing workarounds.

Regards,
Olaf
Re: decvalue for RFC4826 XML fails [message #1829834 is a reply to message #1829167] Sun, 12 July 2020 12:24 Go to previous messageGo to next message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
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
Re: decvalue for RFC4826 XML fails [message #1829939 is a reply to message #1829834] Tue, 14 July 2020 13:20 Go to previous messageGo to next message
Olaf Bergengruen is currently offline Olaf BergengruenFriend
Messages: 80
Registered: November 2018
Member
Wow, Elemer! Impressive how flexible you are.

Do you know already in which compiler version this new -h option will be available?

Thanks,
Olaf
Re: decvalue for RFC4826 XML fails [message #1829941 is a reply to message #1829939] Tue, 14 July 2020 13:54 Go to previous message
Elemer Lelik is currently offline Elemer LelikFriend
Messages: 1120
Registered: January 2015
Senior Member
Hi Olaf,

next version, probably designated 7.2.0; will be available late autumn.

besides that, of course, it is available right now and it can be tested in the development (latest) version in github .

Best regards

Elemer
Previous Topic:Some problem of compiling TTCN suit of LTE
Next Topic:Debugging using Titan Debugger
Goto Forum:
  


Current Time: Wed Jul 28 06:38:31 GMT 2021

Powered by FUDForum. Page generated in 0.01628 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top