| |
ETSI's Bug Tracker |
| Anonymous | Login | Signup for local Mantis account | 02-05-2024 17:42 IST |  |
| Main | My View | View Issues | Change Log | Roadmap | Monitor project |
| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
| 0004270 | Part 01: TTCN-3 Core Language | Clarification | public | 13-10-2008 13:34 | 09-12-2008 20:08 | ||||
| Reporter | Thomas Deiß | ||||||||
| Assigned To | Ina Schieferdecker | ||||||||
| Priority | normal | Severity | minor | Reproducibility | have not tried | ||||
| Status | closed | Resolution | fixed | ||||||
| Platform | OS | OS Version | |||||||
| Product Version | v3.3.2 (published 2008-04) | ||||||||
| Target Version | v4.1.1 (published 2009-06) | Fixed in Version | v4.1.1 (published 2009-06) | ||||||
| Summary | 0004270: Initialization expressions within component types | ||||||||
| Description | Component type definitions may contain declarations of ports, timers, constants, and variables. Constants must have an initial value, timers and variables may have an initial value. The only kind of restriction on the expressions for these initial values is the limitation to 'ConstantExpression' in the BNF for the value of constants. For the default duration of timers and for the initial values of variables no restriction is given, neither in the next, nor in the BNF. When arbitrary expressions are allowed, this raises the question when the expressions are evaluated: at compile time, when 'loading' a module, when starting a test case, or when creating an instance of a component type. To resolve such questions, it is suggested that any value used in a type definition, is described by a constant expression (see CR2152). Such constant expression always evaluate to the same value. To each of the clauses for type definitions that contain values 6.1.2.1 Lists of values 6.1.2.2 Ranges 6.2.3 Records and sets of single types 6.2.4 enumerations 6.2.7 Arrays 6.2.10.1 Component types a restriction should be added that the values have to be defined by constant expressions. | ||||||||
| Tags | No tags attached. | ||||||||
| Clause Reference(s) | 6.1.2.1, 6.1.2.2, 6.2.3, 6.2.4, 6.2.7, 6.2.10.1 | ||||||||
| Source (company - Author) | Nokia Siemens Networks, Thomas Deiß | ||||||||
| Attached Files |  CR4270_ConstantsInTypes.doc [^] (59,392 bytes) 25-11-2008 12:27 CR4270_ConstantsInTypes_v2.doc [^] (62,464 bytes) 26-11-2008 08:25 | ||||||||
 Relationships |
||||||
|
||||||
 Relationships |
|
Notes |
|
|
(0007403) Ina Schieferdecker (reporter) 25-11-2008 11:21 |
Indeed in the BNF all relevant grammar rules go down to constant expression or literals: arrays: singleconstexpr allowed values: constantexpr range: singleconstexpr length: singleconstexpr enumeration: literal In addition, the restrictions in clause 10 on the usage of constant expression within imply what is request by this CR - except for initial values within component type definitions - these however do not need to be further restricted. Some clarifying sentences could be added as it has been done already in CR2152 for arrays ... see uploaded solution. |
|
(0007413) Gyorgy Rethy (reporter) 25-11-2008 14:17 |
In clause 6.2.10.1 "Constants used in the constant expressions of type declarations for variables, constants or ports ..." is unclear as formally no types are declared within components. I propose changing it to "Constants used in the constant expressions declaring sizes of variable, constant, port and timer arrays shall follow the restrictions in clause 10 specified for type and array declarations, however..." I propose not to add ", see in particular restriction c)"; it is sufficient to refer to "restrictions in clause 10" but item c) may change later to other letter while the reference is unchanged in the types clauses. Fine with me otherwise. |
|
(0007436) Thomas Deiß (reporter) 26-11-2008 08:26 |
proposed solution as such is ok. Solution extended to remove also the restriction that subtypes have to be true subtypes (relevant for value list, pattern subtyping). v2 uploaded, please crosscheck extension. |
|
Notes |
|
Issue History |
|||
| Date Modified | Username | Field | Change |
| 13-10-2008 13:34 | Thomas Deiß | New Issue | |
| 13-10-2008 13:34 | Thomas Deiß | Status | new => assigned |
| 13-10-2008 13:34 | Thomas Deiß | Assigned To | => Ina Schieferdecker |
| 13-10-2008 13:34 | Thomas Deiß | Clause Reference(s) | => 6.1.2.1, 6.1.2.2, 6.2.3, 6.2.4, 6.2.7, 6.2.10.1 |
| 13-10-2008 13:34 | Thomas Deiß | Source (company - Author) | => Nokia Siemens Networks, Thomas Deiß |
| 25-11-2008 10:26 | Ina Schieferdecker | Relationship added | related to 0002152 |
| 25-11-2008 11:21 | Ina Schieferdecker | Note Added: 0007403 | |
| 25-11-2008 12:27 | Ina Schieferdecker | File Added: CR4270_ConstantsInTypes.doc | |
| 25-11-2008 12:28 | Ina Schieferdecker | Assigned To | Ina Schieferdecker => Thomas Deiß |
| 25-11-2008 12:28 | Ina Schieferdecker | Resolution | open => fixed |
| 25-11-2008 12:28 | Ina Schieferdecker | Target Version | => Edition 4.1.1 (not yet published) |
| 25-11-2008 14:17 | Gyorgy Rethy | Note Added: 0007413 | |
| 26-11-2008 08:25 | Thomas Deiß | File Added: CR4270_ConstantsInTypes_v2.doc | |
| 26-11-2008 08:26 | Thomas Deiß | Note Added: 0007436 | |
| 26-11-2008 08:26 | Thomas Deiß | Assigned To | Thomas Deiß => Ina Schieferdecker |
| 09-12-2008 20:08 | Ina Schieferdecker | Status | assigned => resolved |
| 09-12-2008 20:08 | Ina Schieferdecker | Fixed in Version | => Edition 4.1.1 (not yet published) |
| 09-12-2008 20:08 | Ina Schieferdecker | Status | resolved => closed |
|
Issue History |
| MantisBT 1.2.14 [^] Copyright © 2000 - 2024 MantisBT Team |
 |