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

ID | Project | Category | View Status | Date Submitted | Last Update
0006669 | Part 06: TTCN-3 Control Interface | Technical | public | 10-01-2014 12:53 | 17-12-2014 11:42

Reporter | Tomas Urban |
Assigned To | Tomas Urban |
Priority | normal | Severity | major | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 7.3.2.2
Source (company - Author) | Elvior

Summary | 0006669: Missing support for decvalue function in TCI

Description

The decvalue function defined in the C.5.2 of the core language specification requires that the decoder appart from decoding the value (or not decoding it) provides two additional values:
1. If the decoding process didn't use the whole supplied bitstring for the decoding, the undecoded part
2. If the decoding process didn't succeed, the method returns 2 if the reason is insufficient number of bytes to decode or 1 in case of any other (unspecified) cause.
Neither of these two additional values can be obtained through the TCI-CD provided interface, because its decode method of the interface return just the decoded value or null. This makes the decvalue function work completely only with proprietary codec interfaces, while its use with TCI is restricted to return values 0 and 1 and the undecoded part equal to an empty bit string.
Since changing the TCI decode function signature wouldn't be feasible because of compatibility issues, I propose to add a new function to the TCI-CD provided interface:
TInteger decValue(inout TriMessageType, in TypeHypothesis decodingHyporthesis, out Value decodedValue)

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6699_v1.docx (14,648) 16-06-2014 13:51 http://oldforge.etsi.org/mantis/file_download.php?file_id=3031&type=bug

Issue History
Date Modified | Username | Field | Change
10-01-2014 12:53 | Tomas Urban | New Issue |
10-01-2014 12:53 | Tomas Urban | Clause Reference(s) | => 7.3.2.2
10-01-2014 12:53 | Tomas Urban | Source (company - Author) | => Elvior
07-04-2014 14:36 | Gyorgy Rethy | Note Added: 0011942 |
07-04-2014 14:38 | Gyorgy Rethy | Assigned To | => Tomas Urban
07-04-2014 14:38 | Gyorgy Rethy | Status | new => assigned
08-04-2014 17:07 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
30-04-2014 09:31 | Jacob Wieland - Spirent | Note Added: 0012060 |
16-06-2014 13:51 | Tomas Urban | File Added: CR6699_v1.docx |
16-06-2014 13:51 | Tomas Urban | Note Added: 0012085 |
16-06-2014 13:51 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
16-06-2014 13:51 | Tomas Urban | Status | assigned => confirmed
17-06-2014 07:22 | Jacob Wieland - Spirent | Note Added: 0012095 |
08-10-2014 08:11 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
08-10-2014 08:11 | Gyorgy Rethy | Status | confirmed => resolved
08-10-2014 08:11 | Gyorgy Rethy | Resolution | open => fixed
08-10-2014 08:11 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)
17-12-2014 11:42 | Tomas Urban | Status | resolved => closed

Notes

(0011942)
Gyorgy Rethy
07-04-2014 14:36

stf478, 2014-04-07: (1) a new function should be added to return the decoding result value. (2) start a discussion thread with tool vendors if a common error handling and fallback mechanism could be agreed.

(0012060)
Jacob Wieland - Spirent
30-04-2014 09:31

As we also encountered the case that a codec shall behave differently when decoding a received message and decoding via decvalue, Testing Technologies would also appreciate a new function tciDecValue (and, of course, tciEncValue). This way, we would solve two issues with one CR ;-)

(0012085)
Tomas Urban
16-06-2014 13:51

Proposal uploaded. Please check.

(0012095)
Jacob Wieland - Spirent
17-06-2014 07:22

fine by me