ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006783 | Part 01: TTCN-3 Core Language | Technical | public | 19-06-2014 12:21 | 04-01-2015 21:19

Reporter | Gyorgy Rethy |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | always
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2014-06) |
Target Version | v4.7.1 (published 2015-06) | Fixed in Version | v4.7.1 (published 2015-06) |
Clause Reference(s) | 22.3.6
Source (company - Author) | L.M.Ericsson

Summary | 0006783: Wrong syntax to save exception parameters

Description

In the Syntactical Structure part for the Catch operation, the "storing message part" syntax is used:
[ "->" [ value ( VariableRef |
( "(" { VariableRef [ ":=" FieldOrTypeReference ][","] } ")" )
) ]
instead of "storing the parameter" syntax used in other procedure-based operations, e.g. in getreply, where storing the whole reply is using the value keyword and storing individual parameters is using the param keyword:
[ "->" [ value VariableRef ]
[ param "(" { ( VariableRef ":=" ParameterIdentifier ) "," } |
{ ( VariableRef | "-" ) "," }
")" ]

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

Relationships

related to | 0006736 | closed | Gyorgy Rethy | new matching mechanism for binary string types

Attached Files | CR6783_v1.docx (65,026) 20-06-2014 08:24 http://oldforge.etsi.org/mantis/file_download.php?file_id=3065&type=bug CR6783_v1_alt.docx (56,064) 20-06-2014 08:26 http://oldforge.etsi.org/mantis/file_download.php?file_id=3066&type=bug CR6783_v3.docx (16,586) 09-10-2014 12:09 http://oldforge.etsi.org/mantis/file_download.php?file_id=3127&type=bug

Issue History
Date Modified | Username | Field | Change
19-06-2014 12:21 | Gyorgy Rethy | New Issue |
19-06-2014 12:31 | Jacob Wieland - Spirent | Note Added: 0012141 |
19-06-2014 15:07 | Gyorgy Rethy | Note Added: 0012149 |
19-06-2014 15:07 | Gyorgy Rethy | Description Updated | bug_revision_view_page.php?rev_id=43#r43
20-06-2014 07:52 | Tomas Urban | Assigned To | => Tomas Urban
20-06-2014 07:52 | Tomas Urban | Status | new => assigned
20-06-2014 08:06 | Jacob Wieland - Spirent | Note Added: 0012168 |
20-06-2014 08:24 | Tomas Urban | File Added: CR6783_v1.docx |
20-06-2014 08:26 | Tomas Urban | File Added: CR6783_v1_alt.docx |
20-06-2014 08:38 | Tomas Urban | Note Added: 0012170 |
20-06-2014 08:38 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
20-06-2014 08:38 | Tomas Urban | Status | assigned => confirmed
20-06-2014 08:39 | Tomas Urban | Note Edited: 0012170 | bug_revision_view_page.php?bugnote_id=12170#r57
20-06-2014 11:38 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
08-10-2014 09:27 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch
08-10-2014 15:57 | Axel Rennoch | Note Added: 0012289 |
08-10-2014 15:57 | Axel Rennoch | Assigned To | Axel Rennoch => Gyorgy Rethy
08-10-2014 15:57 | Axel Rennoch | Status | confirmed => assigned
08-10-2014 15:58 | Axel Rennoch | Note Added: 0012290 |
08-10-2014 15:58 | Axel Rennoch | Status | assigned => confirmed
08-10-2014 16:21 | Gyorgy Rethy | Note Added: 0012296 |
08-10-2014 16:21 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Axel Rennoch
09-10-2014 10:29 | Gyorgy Rethy | Note Added: 0012312 |
09-10-2014 12:09 | Axel Rennoch | File Added: CR6783_v3.docx |
09-10-2014 12:10 | Axel Rennoch | Note Added: 0012316 |
09-10-2014 12:45 | Axel Rennoch | Assigned To | Axel Rennoch => Tomas Urban
09-10-2014 12:45 | Axel Rennoch | Status | confirmed => assigned
09-10-2014 12:46 | Axel Rennoch | Note Added: 0012321 |
09-10-2014 12:46 | Axel Rennoch | Status | assigned => confirmed
09-10-2014 14:13 | Tomas Urban | Relationship added | related to 0006736
09-10-2014 14:18 | Tomas Urban | Note Added: 0012325 |
09-10-2014 14:18 | Tomas Urban | Status | confirmed => resolved
09-10-2014 14:18 | Tomas Urban | Resolution | open => fixed
09-10-2014 14:18 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
04-01-2015 21:19 | Gyorgy Rethy | Note Added: 0012617 |
04-01-2015 21:19 | Gyorgy Rethy | Status | resolved => closed
04-01-2015 21:19 | Gyorgy Rethy | Fixed in Version | => v4.7.1 (published 2015-06)

Notes

(0012141)
Jacob Wieland - Spirent
19-06-2014 12:31

Exceptions have no parameters. They are a special kind of message.

(0012149)
Gyorgy Rethy
19-06-2014 15:07

STF discussion: in the BNF separate message and procedure storing rules. Delete storing part of messages for the Catch operation.

(0012168)
Jacob Wieland - Spirent
20-06-2014 08:06

I still don't understand the issue here at all. What's wrong with something that has been working for years? If an exception is caught, there are no parameters to be assigned, just the exception value. Therefore, storing it like a message makes more sense than storing it like a parameter list.

(0012170)
Tomas Urban
20-06-2014 08:38 (edited on: 20-06-2014 08:39)

I prepared two alternative solutions. The first one (CR6783_v1.docx) unifies the value redirect for getreply and catch so that only the simple syntax is allowed as requested in the CR.
However, since the current catch statement actually describes the extended syntax, the alternative proposal (CR6783_v1_alt.docx) changes only the BNF so that only the getreply statement uses the simplified form. Since the base proposal also affects the text of the catch operation, I am afraid that it would introduce backwards incompatibility. If the alternative proposal is taken into use instead of the base one, similar changes as in 0006736 shall be made in the syntax description of the catch operation as it still uses the same syntax for value redirect assignments on the BNF level as the receive operation (or the BNF should disallow the @decoded clause for the catch operation).

(0012289)
Axel Rennoch
08-10-2014 15:57

Following the previous STF discussion there should be some unification/modification of the storing rules and the first resolution may be selected. However we may think about also allowing the "previous" syntax for keeping backward compatibility, as a deprecated approach?

(0012290)
Axel Rennoch
08-10-2014 15:58

The CR solution may need a final STF decision.

(0012296)
Gyorgy Rethy
08-10-2014 16:21

Axel, pls. keep the CR at yourself until the STF decision.

(0012312)
Gyorgy Rethy
09-10-2014 10:29

STF discussion: correct getreply syntax in text to be in synch with BNF and allow extended reference. Catch is in principle OK, but check consistency of the text with the BNF. Also make those changes in CR 6736

(0012316)
Axel Rennoch
09-10-2014 12:10

new syntax part for getreply in text (also considering CR6736_v5).

(0012321)
Axel Rennoch
09-10-2014 12:46

Please confirm latest update following the STF discussion

(0012325)
Tomas Urban
09-10-2014 14:18

The proposed resolution fixes the problem by extending the syntactical description of the getvalue operation. It is ready to be added to the next version of the TTCN-3 standard. Please make sure that the changes proposed in the resolution of the related CR 0006736 are not overwritten by this CR.

(0012617)
Gyorgy Rethy
04-01-2015 21:19

Added to drfat V4.6.3