ETSI's Bug Tracker - Part 06: TTCN-3 Control Interface
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0005885 | Part 06: TTCN-3 Control Interface | Clarification | public | 11-05-2011 10:36 | 16-12-2011 06:06

Reporter | tepelmann |
Assigned To | Ina Schieferdecker |
Priority | high | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.4.1 (published 2012-04) | Fixed in Version | v4.4.1 (published 2012-04) |
Clause Reference(s) | 9.2, 9.6, 10.5.3.7
Source (company - Author) | Testing Technologies IST GmbH - tepelmann

Summary | 0005885: Inconsistency in mapping UniversalCharstringValue (implies platform dependency)

Description

I noticed a change in the ANSI C mapping of the UniversalCharstringValue from version 4.1.1 to 4.2.1.
In 4.1.1 the type TciUCValue was used for all relevant operations, where in 4.2.1 wchar_t is used.
To remind what was TciUCValue - an array of 4 bytes:
typedef unsigned char TciUCValue[4];
I'm wondering if the replacement with wchar_t was correct or not. The reason is that wchar_t has a different size on different platforms, on Unix system mostly 4 bytes, on Windows system 2 bytes.
I'm not sure if this could cause any inconsistency when interworking between two different systems. As this could cause different encoding and decoding in the case the communication is taking place between to different platforms.
Please clarify this.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0005489 | closed | Ina Schieferdecker | TCI C++ mapping fixes

Attached Files |

Issue History
Date Modified | Username | Field | Change
11-05-2011 10:36 | tepelmann | New Issue |
11-05-2011 10:36 | tepelmann | Clause Reference(s) | => 9.2, 9.6, 10.5.3.7
11-05-2011 10:36 | tepelmann | Source (company - Author) | => Testing Technologies IST GmbH - tepelmann
24-05-2011 12:12 | Gyorgy Rethy | Note Added: 0010006 |
24-05-2011 12:13 | Gyorgy Rethy | Status | new => assigned
24-05-2011 12:13 | Gyorgy Rethy | Assigned To | => Ina Schieferdecker
24-05-2011 18:07 | Gyorgy Rethy | Target Version | => Edition 4.3.2 (interim)
24-05-2011 19:13 | Gyorgy Rethy | Priority | normal => high
24-05-2011 19:26 | Gyorgy Rethy | Target Version | Edition 4.3.2 (interim) => Edition 4.4.1
24-05-2011 19:26 | Gyorgy Rethy | Target Version | Edition 4.4.1 => Edition 4.3.2 (interim)
25-05-2011 18:04 | Ina Schieferdecker | Relationship added | related to 0005489
25-05-2011 18:35 | Ina Schieferdecker | Note Added: 0010074 |
27-09-2011 13:58 | Gyorgy Rethy | Target Version | Edition 4.3.2 (interim) => Edition 4.4.1
30-11-2011 11:07 | Ina Schieferdecker | Note Added: 0010432 |
30-11-2011 11:07 | Ina Schieferdecker | Note Added: 0010433 |
30-11-2011 11:08 | Ina Schieferdecker | Note Added: 0010434 |
30-11-2011 11:09 | Ina Schieferdecker | Note Added: 0010435 |
02-12-2011 13:51 | Ina Schieferdecker | Note Added: 0010522 |
02-12-2011 13:56 | Ina Schieferdecker | Note Added: 0010523 |
02-12-2011 13:57 | Ina Schieferdecker | Note Added: 0010524 |
02-12-2011 13:57 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Jacob Wieland - Spirent
02-12-2011 15:35 | Jacob Wieland - Spirent | Note Added: 0010529 |
03-12-2011 05:49 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
16-12-2011 06:05 | Ina Schieferdecker | Note Added: 0010542 |
16-12-2011 06:05 | Ina Schieferdecker | Status | assigned => resolved
16-12-2011 06:05 | Ina Schieferdecker | Resolution | open => fixed
16-12-2011 06:05 | Ina Schieferdecker | Fixed in Version | => Edition 4.4.1
16-12-2011 06:06 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010006)
Gyorgy Rethy
24-05-2011 12:12

It has been defined as wchar_t based on CR5489 in discussion with vendors. Proposal is to leave xchar_t but tool implementations shall take care of using a 4 octet representation. This proposal shall be agreed with tool vendors.

(0010074)
Ina Schieferdecker
25-05-2011 18:35

This subject indeed requires some more thoughts ... according to my reads the native support for 4 byte universal characters is open in quite some programming languages/operating systems/compilers. As there is a need for a correct solution and, if possible, one that is comparable to the different language mappings, what about getting indeed back to the 4 byte array of character?

(0010432)
Ina Schieferdecker
30-11-2011 11:07

Dear all Please also have a look at http://t-ort.etsi.org/view.php?id=5885 [^] which is about the representation of universal characters in the language mappings. Either, we leave it as is and require the implementations to have a wchar_t setting that is capable of representing universal characters. Or, we return to the original solution with a 4 byte array of character. Best regards Ina

(0010433)
Ina Schieferdecker
30-11-2011 11:07

Hi,
Both solutions are Ok for Elvior but wchar_t is better because functions exist for that. Of course there exists systems where wchar_t is only 16 bits and there is the risk of losing data. Maybe the better solution would be if TRI will include 2 type functions - for wchar_t and for old structure. In that way one can choose the function he/she likes.
Best Regards,
Andres Kull | Founder & Chief Research Officer |Elvior

(0010434)
Ina Schieferdecker
30-11-2011 11:08

Dear Ina, we would prefer a clean, easy to implement but platform independent solution here. With best regards, Thilo Lauer, Devoteam

(0010435)
Ina Schieferdecker
30-11-2011 11:09

Dear all, OpenTTCN thinks that having 4 byte / 32 bit representation is more accurate for representing characters of universal charstring type. Using data type of less than 32 bits would require to have error handling defined in the standard if trying to access data that cannot be represented using <32 bits. Kind regards, Vesa-Matti

(0010522)
Ina Schieferdecker
02-12-2011 13:51

STF decided to get back to the C original presentation of universal char as 4 byte array.

(0010523)
Ina Schieferdecker
02-12-2011 13:56

void tciGetUCStringCharValue (Value inst, unsigned long int position, TciUCValue result) void tciSetUCStringCharValue (Value inst, unsigned long int position, TciUCValue value) typedef unsigned char TciUCValue[4] typedef struct TciUCStringValue { unsigned long int length; TciUCValue *string; } TciUCStringValue;

(0010524)
Ina Schieferdecker
02-12-2011 13:57

Please check

(0010529)
Jacob Wieland - Spirent
02-12-2011 15:35

seems ok

(0010542)
Ina Schieferdecker
16-12-2011 06:05

As proposed.