ETSI's Bug Tracker - TTCN-3 Change Requests
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006630 | TTCN-3 Change Requests | Technical | public | 07-10-2013 14:58 | 26-12-2013 12:54

Reporter | Tomas Urban |
Assigned To | Jens Grabowski |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Clause Reference(s) | A.2
For STF discussion |
Source (company - Author) | Elvior

Summary | 0006630: Continuous signalling: withdrawing BNF support for labels in the par statement

Description

The BNF allows to declare labels inside the par statement body. However, it is not possible to jump to these labels because of a restriction on the use of the goto command in par statements (see 5.4.1.1.2 for more details). I don't think it is wise to support syntax that has no useful meaning and therefore I propose to change the BNF so that the labels are syntactically allowed only inside the seq statement:
51.ModeSpecification ::= ( BasicMode | SeqMode | ParMode ) [ UntilBlock ]
62a. SeqMode ::= SeqKeyword " {" {VarInstance}
[OnEntryBlock]
[InvariantBlock]
ModeList
[OnExitBlock]
" }"
62b.ParMode ::= ParKeyword " {" {VarInstance}
[OnEntryBlock]
[InvariantBlock]
{ ModeSpecification }
[OnExitBlock]
" }"

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR6630-Res-V1-131008.doc (118,784) 08-10-2013 10:53 http://oldforge.etsi.org/mantis/file_download.php?file_id=2895&type=bug

Issue History
Date Modified | Username | Field | Change
07-10-2013 14:58 | Tomas Urban | New Issue |
07-10-2013 14:58 | Tomas Urban | Clause Reference(s) | => A.2
07-10-2013 14:58 | Tomas Urban | Source (company - Author) | => Elvior
08-10-2013 09:13 | Tomas Urban | Note Added: 0011695 |
08-10-2013 10:09 | Jens Grabowski | Status | new => assigned
08-10-2013 10:09 | Jens Grabowski | Assigned To | => Jens Grabowski
08-10-2013 10:53 | Jens Grabowski | Note Added: 0011698 |
08-10-2013 10:53 | Jens Grabowski | File Added: CR6630-Res-V1-131008.doc |
08-10-2013 10:53 | Jens Grabowski | Assigned To | Jens Grabowski => Jacob Wieland - Spirent
08-10-2013 11:15 | Jacob Wieland - Spirent | Note Added: 0011699 |
08-10-2013 11:17 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Jens Grabowski
08-10-2013 11:17 | Jacob Wieland - Spirent | Status | assigned => confirmed
08-10-2013 11:34 | Tomas Urban | Note Added: 0011701 |
26-12-2013 12:54 | Jens Grabowski | Status | confirmed => closed
26-12-2013 12:54 | Jens Grabowski | Resolution | open => fixed

Notes

(0011695)
Tomas Urban
08-10-2013 09:13

I also noticed there's no semicolon separator support inside complex modes, so the rules so the rule for the par statement should be: 62b.ParMode ::= ParKeyword "{" {VarInstance} [OnEntryBlock] [InvariantBlock] { ModeSpecification [SemiColon] } [OnExitBlock] "}" and the rule 65 should be: 65.ModeList ::= { [LabelStatement [SemiColon] ] ModeSpecification [SemiColon]}

(0011698)
Jens Grabowski
08-10-2013 10:53

Implemented according to proposal of Tomas. Assigned to Jacob for cross-checking.

(0011699)
Jacob Wieland - Spirent
08-10-2013 11:15

In principle okay, but I don't think we need the semicolons (except for the label statement where it should be mandatory according to the normal semicolon rules) as there can never be any ambiguity which needs to be resolved with the semicolon (all modes end with a closing bracket which makes the semicolon superfluous).

(0011701)
Tomas Urban
08-10-2013 11:34

All modes do not end with curly brackets: there might be parametrized mode instances inside complex modes (see e.g. example 2 in 5.4.5.2) and this is the reason why the second optional semicolon should be in the rule as well.