ETSI's Bug Tracker - Part 01: TTCN-3 Core Language
View Issue Details
0007729Part 01: TTCN-3 Core LanguageEditorialpublic22-11-2017 13:2804-01-2019 16:45
Philip Makedonski 
Gyorgy Rethy 
normalminorhave not tried
closedfixed 
v4.8.1 (published 2016-07) 
4.11.1 (published 2019-05)4.11.1 (published 2019-05) 
Clause 8.2.3.1
     University of Göttingen, Philip Makedonski
0007729: There seems to be a mistake in Example 4 on Page 108 (v4.9.1)
There seems to be a mistake in Example 4 in Clause 8.2.3.1 on Page 108 (v4.9.1):

EXAMPLE 4: Name clash between enumerated values and global definitions
module A {
  type enumerated MyEnumType {enumX, enumY}
  type enumerated MyEnumType2 {enumY, enumZ}
}

module B {
  import from A all;
  const MyEnumType enumY := enumX; // this is not allowed as enumerated values restrict
                                                                     // global names (see clause 6.2.4)
  const MyEnumType2 enumX := enumY; // this is likewise not allowed
                                                                       // PM: WRONG! It should either be noted as allowed
                                                                       // or changed to MyEnumType2 enumZ := enumY
                                                                       // since MyEnumType2 does not contain enumX
  const MyEnumType enumZ := enumX; // allowed as MyEnumType does not contain enumZ
}

I'm guessing what was intended was "const MyEnumType2 enumZ := enumY", especially, considering the fact that the same example continues with:

module C {
  import from A all;
  import from B all;
  const integer enumZ := 0;
  const integer enumY := 1;
  const MyEnumType2 enumX := enumY; // PM: this is identical to the example above and should be allowed
  //...
}
No tags attached.
docx CR7729.docx (183,748) 19-07-2018 10:03
http://oldforge.etsi.org/mantis/file_download.php?file_id=3772&type=bug
Issue History
22-11-2017 13:28Philip MakedonskiNew Issue
24-11-2017 12:00Jacob Wieland - SpirentNote Added: 0014923
04-01-2018 17:27Gyorgy RethyNote Added: 0014997
05-01-2018 13:59Gyorgy RethyTarget Version => 4.11.1 (published 2019-05)
16-07-2018 13:27Jens GrabowskiNote Added: 0015127
16-07-2018 13:27Jens GrabowskiAssigned To => Jacob Wieland - Spirent
16-07-2018 13:27Jens GrabowskiStatusnew => assigned
19-07-2018 10:03Jacob Wieland - SpirentFile Added: CR7729.docx
19-07-2018 10:04Jacob Wieland - SpirentNote Added: 0015169
19-07-2018 10:04Jacob Wieland - SpirentAssigned ToJacob Wieland - Spirent => Tomas Urban
19-07-2018 10:04Jacob Wieland - SpirentStatusassigned => confirmed
19-07-2018 10:43Tomas UrbanNote Added: 0015170
19-07-2018 10:43Tomas UrbanAssigned ToTomas Urban => Gyorgy Rethy
19-07-2018 10:43Tomas UrbanStatusconfirmed => resolved
04-01-2019 16:45Gyorgy RethyNote Added: 0015299
04-01-2019 16:45Gyorgy RethyStatusresolved => closed
04-01-2019 16:45Gyorgy RethyResolutionopen => fixed
04-01-2019 16:45Gyorgy RethyFixed in Version => 4.11.1 (published 2019-05)

Notes
(0014923)
Jacob Wieland - Spirent   
24-11-2017 12:00   
I think the first examples were originally also in the same module as the enum type definitions and thus giving the module-prefix was not resolving the ambiguity (which is why that is disallowed).

So, I think the complaint is correct.
(0014997)
Gyorgy Rethy   
04-01-2018 17:27   
I also think the CR is correct, if it can be agreed by mid January, could be corrected in the coming version V4.10.1.
(0015127)
Jens Grabowski   
16-07-2018 13:27   
STF discussion: CR is correct. Jacob will work on a proposal.
(0015169)
Jacob Wieland - Spirent   
19-07-2018 10:04   
please review, I simply changed the wrong comment
(0015170)
Tomas Urban   
19-07-2018 10:43   
Reviewed, no issues found. The proposal is ready to be added to the next version of the core language standard.
(0015299)
Gyorgy Rethy   
04-01-2019 16:45   
Added to draft V4.10.2