ETSI's Bug Tracker - Part 01: TTCN-3 Core Language |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0005518 | Part 01: TTCN-3 Core Language | New Feature | public | 23-04-2010 10:32 | 14-12-2010 13:20 |
|
| Reporter | Gyorgy Rethy | |
| Assigned To | Ina Schieferdecker | |
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | | OS | | OS Version | |
| Product Version | v4.1.1 (published 2009-06) | |
| Target Version | v4.3.1 (published 2011-06) | Fixed in Version | v4.3.1 (published 2011-06) | |
| Clause Reference(s) | new |
| Source (company - Author) | L.M.Ericsson |
|
| Summary | 0005518: Add int2enum predefined function |
| Description | Converting between the enumareted and integer type has been a pain in TTCN-3, required - in worth case - two external functions for each enumerated (OK, in real life less, but still...). Introducing enum2int solved half of the problem. users like it. But now users are requesting the "second half" of the solution, conversion from integer to enumerated. Reasons of - at least one of the users - are:
"I have some values which are (correctly) handled by test ports as integer types.
But, I'd like to internally handle them as enumerated, for several reasons:
- there is a finite number of values for them.
- enum values are more human readable in source code than integer.
- ttcn log shows enum values with both: label and integer values
(const values are only shown as integer, without its label value).
So, when receiving these values, I found the need to convert
them from integer to the internal enumerated value.
Is there an elegant way to solve this (better than a select/case function)?" |
| Steps To Reproduce | |
| Additional Information | Proposed solution: introduce the int2enum predefined function with the signature:
int2enum (in integer int, out <any defined enumerated type> enum) returm integer;
i.e. the second parameter shall be a variable and the type of this variable defines the enumerated type to which the integer has to be mapped. The return value shall return 0 if the conversion is successful or non-zero if unsuccessful (it needs further discussion if we want to differentiate the erro cases - and how many of them). I think it is needed because in the case of an integer->enum conversion there is quite a high probability that the in integer value does not have an equivalent enum value. If not handling this type of error case via the return value, user who wants to write a robust code ends up with select case statements again and, in fact, the int2enum predefined function would become useless. |
| Tags | No tags attached. |
| Relationships | |
| Attached Files |  CR5518-Resolution-Jens-100630.zip (39,856) 30-06-2010 18:34
http://oldforge.etsi.org/mantis/file_download.php?file_id=2390&type=bug
 CR5518-Resolution-Gyorgy-100701.doc (212,480) 01-07-2010 09:07
http://oldforge.etsi.org/mantis/file_download.php?file_id=2391&type=bug
CR5518-Resolution-Jens-100830.doc (213,504) 31-08-2010 09:28
http://oldforge.etsi.org/mantis/file_download.php?file_id=2417&type=bug
CR5518-Resolution-101201.doc (213,504) 01-12-2010 09:26
http://oldforge.etsi.org/mantis/file_download.php?file_id=2447&type=bug |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 23-04-2010 10:32 | Gyorgy Rethy | New Issue | |
| 23-04-2010 10:32 | Gyorgy Rethy | Clause Reference(s) | => new |
| 23-04-2010 10:32 | Gyorgy Rethy | Source (company - Author) | => L.M.Ericsson |
| 28-06-2010 16:38 | Gyorgy Rethy | Status | new => assigned |
| 28-06-2010 16:38 | Gyorgy Rethy | Assigned To | => Jens Grabowski |
| 29-06-2010 10:48 | Gyorgy Rethy | Note Added: 0009397 | |
| 29-06-2010 10:48 | Gyorgy Rethy | Target Version | => Edition 4.3.1 (not yet published) |
| 30-06-2010 18:34 | Jens Grabowski | File Added: CR5518-Resolution-Jens-100630.zip | |
| 30-06-2010 18:35 | Jens Grabowski | Note Added: 0009438 | |
| 30-06-2010 18:35 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
| 01-07-2010 09:07 | Gyorgy Rethy | Note Added: 0009440 | |
| 01-07-2010 09:07 | Gyorgy Rethy | File Added: CR5518-Resolution-Gyorgy-100701.doc | |
| 01-07-2010 09:08 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker |
| 01-07-2010 09:08 | Gyorgy Rethy | Status | assigned => resolved |
| 01-07-2010 09:08 | Gyorgy Rethy | Resolution | open => fixed |
| 01-07-2010 09:08 | Gyorgy Rethy | Fixed in Version | => Edition 4.2.2 (not yet published) |
| 05-07-2010 13:43 | Jacob Wieland - Spirent | Status | resolved => feedback |
| 05-07-2010 13:43 | Jacob Wieland - Spirent | Resolution | fixed => reopened |
| 05-07-2010 13:43 | Jacob Wieland - Spirent | Note Added: 0009479 | |
| 13-07-2010 11:47 | Gyorgy Rethy | Note Added: 0009518 | |
| 30-08-2010 12:22 | Gyorgy Rethy | Status | feedback => assigned |
| 30-08-2010 12:22 | Gyorgy Rethy | Assigned To | Ina Schieferdecker => Jens Grabowski |
| 31-08-2010 09:28 | Jens Grabowski | File Added: CR5518-Resolution-Jens-100830.doc | |
| 31-08-2010 09:31 | Jens Grabowski | Note Added: 0009659 | |
| 31-08-2010 09:31 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy |
| 01-12-2010 09:26 | Gyorgy Rethy | File Added: CR5518-Resolution-101201.doc | |
| 01-12-2010 09:28 | Gyorgy Rethy | Note Added: 0009873 | |
| 01-12-2010 09:28 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Ina Schieferdecker |
| 01-12-2010 09:28 | Gyorgy Rethy | Status | assigned => resolved |
| 01-12-2010 09:28 | Gyorgy Rethy | Resolution | reopened => fixed |
| 01-12-2010 09:28 | Gyorgy Rethy | Fixed in Version | Edition 4.2.2 (not yet published) => Edition 4.3.1 (not yet published) |
| 14-12-2010 12:52 | Ina Schieferdecker | Note Added: 0009963 | |
| 14-12-2010 13:20 | Ina Schieferdecker | Status | resolved => closed |
|
Notes |
|
|
|
|
Agreed in principle, create proposed text. |
|
|
|
|
|
Resolution Version 1 uploaded, assigned to György for proofreading. |
|
|
|
|
|
Its OK, just some minor editorials. See CR5518-Resolution-Gyorgy-100701.doc. |
|
|
|
|
|
I would strongly vote for a void-function and treat the error cases as with all other conversion functions as a testcase error. The proposed approach seems inconsistent with the rest of the language in that regard. Error handling should not be necessary on the TTCN-3 language level. |
|
|
|
|
|
This is also a possible approach, OK, don't include this CR to v4.2.2 but let leave the discussion for the next session. |
|
|
|
|
|
Last note from Jacob was accepted and the resolution from 30.08.2010 resolves the CR accordingly. Assigned for proofreading to György. |
|
|
|
|
|
One minor editorial in aneex C text, "converts and integer value" -> "converts an integer value". Final version is in CR5518-Resolution-101201.doc |
|
|
|
|
|