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

ID | Project | Category | View Status | Date Submitted | Last Update
0007754 | Part 01: TTCN-3 Core Language | Clarification | public | 08-03-2018 09:32 | 04-01-2019 16:53

Reporter | Thilo Lauer |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.9.1 (published 2017-05) |
Target Version |  | Fixed in Version | 4.11.1 (published 2019-05) |
Clause Reference(s) | ES 201 873-1 v4.9.1
Source (company - Author) | Devoteam - Thilo Lauer

Summary | 0007754: Clarify initialization of constants and module parameters

Description

Clarification required on following subject:
The current standard version does not clearly define, wheather initialization of a constant with module parameters is allowed or not.
If constant initializations by module parameters shall be permitted, than the semantic for default values of such module parameters needs to be clarified.
Example 1:
modulepar integer px_int1 := tsc_const1 + 3;
modulepar integer px_int2; // note: no default value assigned here!
const integer tsc_const1 := px_int2;
Should this example be allowed and what is the semantic of it?
Notes:
- px_int2 must be provided at runtime (e.g. by a module-parameter file)
- px_int1 could be provided at runtime, but if not, it can be computed by
the default-expression
- tsc_const1 must be computed at runtime as its value depends on
module parameters
- if px_int2 value is NOT provided at runtime, should this lead to
an error message anyway or only if px_int1, px_int2, tsc_const1 are
really used in a test run?
And should there be a warning issued at compile time, that this may
lead to an error at runtime?
If it should be allowed to init a constant by module parameter values, what about the following example:
Example 2:
modulepar integer px_int3 := tsc_const2 + 3;
const integer tsc_const2 := px_int3;
Our clarification suggestion would be:
- module parameters can be initialized by using constants, but
- constant values SHALL NOT depend on module parameters
A clarification would be helpful here.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.
Relationships |
Attached Files | CR-7754 Clarify initialization of constants and module parameters.docx (69,445) 19-07-2018 11:07 http://oldforge.etsi.org/mantis/file_download.php?file_id=3774&type=bug

Issue History
Date Modified | Username | Field | Change
08-03-2018 09:32 | Thilo Lauer | New Issue |
08-03-2018 13:09 | Jacob Wieland - Spirent | Note Added: 0015063 |
16-07-2018 13:48 | Jens Grabowski | Note Added: 0015130 |
16-07-2018 13:49 | Jens Grabowski | Assigned To | => Jens Grabowski
16-07-2018 13:49 | Jens Grabowski | Status | new => assigned
18-07-2018 10:39 | Jens Grabowski | Note Added: 0015156 |
18-07-2018 11:02 | Jens Grabowski | Note Added: 0015157 |
18-07-2018 15:08 | Jens Grabowski | Note Added: 0015164 |
19-07-2018 11:01 | Jens Grabowski | Note Added: 0015171 |
19-07-2018 11:07 | Jens Grabowski | File Added: CR-7754 Clarify initialization of constants and module parameters.docx |
19-07-2018 11:08 | Jens Grabowski | Note Added: 0015173 |
19-07-2018 11:08 | Jens Grabowski | Assigned To | Jens Grabowski => Tomas Urban
19-07-2018 11:08 | Jens Grabowski | Status | assigned => confirmed
19-07-2018 13:29 | Tomas Urban | Note Added: 0015177 |
19-07-2018 13:29 | Tomas Urban | Status | confirmed => resolved
19-07-2018 13:29 | Tomas Urban | Resolution | open => fixed
19-07-2018 13:29 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
04-01-2019 16:53 | Gyorgy Rethy | Note Added: 0015301 |
04-01-2019 16:53 | Gyorgy Rethy | Status | resolved => closed
04-01-2019 16:53 | Gyorgy Rethy | Fixed in Version | => 4.11.1 (published 2019-05)

Notes

(0015063)
Jacob Wieland - Spirent
08-03-2018 13:09

I think the actual issue here is the circularity of the default values (const-value being used that is also dependent on that usage).
That, of course, must be disallowed (and probably is).
Otherwise, I see no problem with non-circular usage between constants and modulepar-defaults.
In essence, modulepars are just constants with an unknown value at compile-time, so a constant filled with something depending on a modulepar is also just a constant with an unknown value.
Thus, if it would be allowed for two modulepars, why would it not be allowed for a combination of const and modulepar?
Constants are just values that are initialized once (at the latest before their first usage) and never changed afterwards (during the life-cycle of a testsystem or at least a single testcase-run).
The same is true for modulepars with the additional feature that they can be configured explicitly and can be provided a default value.

(0015130)
Jens Grabowski
16-07-2018 13:48

STF discussion: Check standard regarding current rules.

(0015156)
Jens Grabowski
18-07-2018 10:39

The example Example 2: modulepar integer px_int3 := tsc_const2 + 3; const integer tsc_const2 := px_int3; is not allowed. The general clause "5.5 Cyclic Definitions" should apply. (The notions "definition" and "declaration" of variables, constants, types and other language elements are used interchangeably.)

(0015157)
Jens Grabowski
18-07-2018 11:02

> Example 1:
>
> modulepar integer px_int1 := tsc_const1 + 3;
> modulepar integer px_int2; // note: no default value assigned here!
> const integer tsc_const1 := px_int2;
>
> Should this example be allowed and what is the semantic of it?
>
> Notes:
> - px_int2 must be provided at runtime (e.g. by a module-parameter file)
YES
> - px_int1 could be provided at runtime, but if not, it can be computed by
> the default-expression
YES
> - tsc_const1 must be computed at runtime as its value depends on
> module parameters
YES
> - if px_int2 value is NOT provided at runtime, should this lead to
> an error message anyway or only if px_int1, px_int2, tsc_const1 are
> really used in a test run?
The standard states:
"If the test system does not provide an actual runtime value for a module parameter, the default value shall be used during test execution, otherwise the actual value provided by the test system."
I.e., the otherwise part applies, but includes a least a typo. I believe the words "shall be" are missing. The correction needs a discussion within the STF.
> And should there be a warning issued at compile time, that this may
> lead to an error at runtime?
A warning is a tool specific issue. The standard cannot prescribe the tool capabilities. However, note may be added.

(0015164)
Jens Grabowski
18-07-2018 15:08

STF discussion:
Restriction "The expression shall evaluate to a value, which is at least partially initialized." has to be added to constant declaration section.
Add sentence to Clause 8.2.0: Module definitions can be evaluated at runtime and can be evaluated in any order. A definition shall be evaluated latest before the first reference to it.
Add note: If a definition is not used, it may not be evaluated at all.

(0015171)
Jens Grabowski
19-07-2018 11:01

The CR is resolved as follows:
In Clause "10 Declaring constants" the restriction
"d) The right hand side of the assignment that initializes a constant shall evaluate to an object that is at least partially initialized."
In the "Semantic Description" part of Clause "8.2.0 General" behind the sentence "Definitions in the module definitions part may be made in any order." the following sentences an note have been added:
"Module definitions can be evaluated at runtime and can be evaluated in any order. A definition shall be evaluated latest before the first reference to it.
NOTE: If a definition is not used, it may not be evaluated at all."
The circularity of the default values is covered by Clause "5.5 Cyclic Definitions".

(0015173)
Jens Grabowski
19-07-2018 11:08

Tomas, please crosscheck.

(0015177)
Tomas Urban
19-07-2018 13:29

Reviewed, no issues found. The proposal is ready to be added to the next version of the core language specification.

(0015301)
Gyorgy Rethy
04-01-2019 16:53

Added to draft V4.10.2