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

ID | Project | Category | View Status | Date Submitted | Last Update
0006430 | Part 01: TTCN-3 Core Language | Technical | public | 28-02-2013 08:04 | 28-11-2013 10:57

Reporter | Tomas Urban |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version |  |
Target Version | v4.6.1 (published 2014-06) | Fixed in Version | v4.6.1 (published 2014-06) |
Clause Reference(s) | 7.1, 11.1, 11.2
Source (company - Author) | Elvior

Summary | 0006430: Use of uninitialized and partially initialized values

Description

The current specification constraints the use of partially initialized variables (11.1 restriction d, 11.2. restriction e). However, no such rule is specified for constants, parameters, templates, module parameters and compound expressions. This leads to situations when the same value content produces an error if the operand is a variable and no error, if it is a compound expression:
var MyRecord v_r := { field1 := 1, field2 := - }
template MyRecord t_r := ?;
match(v_r, t_r); // error, v_r is partially initialized
match({ field1 := 1, field2 := - }, t_r); // no error: no restriction on
// partially initialized compound expressions
Proposal:
The rules for using uninitialized and partially initialized values shall be general for all values.

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

Attached Files

CR6430_resolution_v1.doc (577,024) 10-10-2013 08:48
http://oldforge.etsi.org/mantis/file_download.php?file_id=2915&type=bug
CR6430_resolution_v2.doc (642,560) 10-10-2013 17:44
http://oldforge.etsi.org/mantis/file_download.php?file_id=2923&type=bug
CR6430_resolution_v3.doc (647,168) 11-10-2013 14:43
http://oldforge.etsi.org/mantis/file_download.php?file_id=2931&type=bug
CR6430_resolution_v4.doc (645,632) 28-11-2013 10:56
http://oldforge.etsi.org/mantis/file_download.php?file_id=2955&type=bug

Issue History
Date Modified | Username | Field | Change
28-02-2013 08:04 | Tomas Urban | New Issue |
28-02-2013 08:04 | Tomas Urban | Clause Reference(s) | => 7.1, 11.1, 11.2
28-02-2013 08:04 | Tomas Urban | Source (company - Author) | => Elvior
28-02-2013 08:44 | Jacob Wieland - Spirent | Note Added: 0011332 |
01-03-2013 12:23 | Tomas Urban | Note Added: 0011334 |
01-03-2013 13:25 | Jacob Wieland - Spirent | Note Added: 0011335 |
08-07-2013 15:29 | Jens Grabowski | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-07-2013 15:30 | Jens Grabowski | Status | new => assigned
08-07-2013 15:30 | Jens Grabowski | Assigned To | => Jacob Wieland - Spirent
08-07-2013 15:31 | Jens Grabowski | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
08-07-2013 18:12 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2014-06)
26-08-2013 14:53 | Jacob Wieland - Spirent | Note Added: 0011597 |
08-10-2013 18:00 | Gyorgy Rethy | Note Added: 0011712 |
08-10-2013 18:00 | Gyorgy Rethy | Note Added: 0011713 |
08-10-2013 18:01 | Gyorgy Rethy | Note Deleted: 0011712 |
09-10-2013 12:27 | Jacob Wieland - Spirent | Note Added: 0011728 |
09-10-2013 13:15 | Tomas Urban | Note Added: 0011730 |
09-10-2013 17:11 | Gyorgy Rethy | Note Added: 0011737 |
09-10-2013 17:12 | Gyorgy Rethy | Note Added: 0011738 |
09-10-2013 17:18 | Gyorgy Rethy | Note Edited: 0011737 |
09-10-2013 18:12 | Gyorgy Rethy | Note Edited: 0011738 |
10-10-2013 08:48 | Gyorgy Rethy | File Added: CR6430_resolution_v1.doc |
10-10-2013 08:49 | Gyorgy Rethy | Note Added: 0011740 |
10-10-2013 08:56 | Gyorgy Rethy | Note Added: 0011741 |
10-10-2013 13:03 | Jacob Wieland - Spirent | Note Added: 0011749 |
10-10-2013 13:08 | Jacob Wieland - Spirent | Note Added: 0011750 |
10-10-2013 17:27 | Gyorgy Rethy | Note Added: 0011760 |
10-10-2013 17:44 | Gyorgy Rethy | File Added: CR6430_resolution_v2.doc |
10-10-2013 17:46 | Gyorgy Rethy | Note Added: 0011761 |
10-10-2013 17:46 | Gyorgy Rethy | Note Edited: 0011761 |
10-10-2013 17:47 | Gyorgy Rethy | Note Edited: 0011760 |
10-10-2013 17:52 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 12:24 | Jacob Wieland - Spirent | Note Added: 0011769 |
11-10-2013 12:26 | Jacob Wieland - Spirent | Note Edited: 0011769 |
11-10-2013 12:29 | Jacob Wieland - Spirent | Note Added: 0011771 |
11-10-2013 12:30 | Jacob Wieland - Spirent | Note Added: 0011772 |
11-10-2013 12:30 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
11-10-2013 12:30 | Jacob Wieland - Spirent | Status | assigned => confirmed
11-10-2013 14:40 | Gyorgy Rethy | File Added: CR6430_resolution_v3.doc |
11-10-2013 14:41 | Gyorgy Rethy | Note Added: 0011784 |
11-10-2013 14:41 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jacob Wieland - Spirent
11-10-2013 14:42 | Gyorgy Rethy | File Deleted: CR6430_resolution_v3.doc |
11-10-2013 14:43 | Gyorgy Rethy | File Added: CR6430_resolution_v3.doc |
11-10-2013 16:31 | Jacob Wieland - Spirent | Status | confirmed => assigned
11-10-2013 16:33 | Jacob Wieland - Spirent | Note Added: 0011793 |
11-10-2013 16:33 | Jacob Wieland - Spirent | Status | assigned => confirmed
11-10-2013 16:34 | Jacob Wieland - Spirent | Status | confirmed => assigned
11-10-2013 16:34 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Ina Schieferdecker
11-10-2013 16:34 | Jacob Wieland - Spirent | Status | assigned => confirmed
28-11-2013 10:56 | Ina Schieferdecker | File Added: CR6430_resolution_v4.doc |
28-11-2013 10:56 | Ina Schieferdecker | Note Added: 0011853 |
28-11-2013 10:57 | Ina Schieferdecker | Status | confirmed => resolved
28-11-2013 10:57 | Ina Schieferdecker | Resolution | open => fixed
28-11-2013 10:57 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
28-11-2013 10:57 | Ina Schieferdecker | Status | resolved => closed

Notes

(0011332)
Jacob Wieland - Spirent
28-02-2013 08:44

In my opinion, constants, templates and module parameters must be fully initialized (i.e. they cannot be partially initialized) as they can not be changed later on (being constant as they are). Leaving parts of constants uninitialized would defy their purpose.
Therefore, restrictions on partially uninitialized constants, templates and module parameters are unnecessary as they cannot exist. That is why the restrictions only apply to things that can be initialized partially, i.e. variables.

(0011334)
Tomas Urban
01-03-2013 12:23

I am afraid I cannot agree. First of all, the current specification doesn't require constants, templates or module parameters to be fully initialized. Besides, uninitialized templates might be useful as base templates for later modifications where the module author intentionally leaves holes for filling by modified templates (using similar design principles as abstract classes in object oriented programming languages).

(0011335)
Jacob Wieland - Spirent
01-03-2013 13:25

If it was possible to declare these templates as abstract, I would agree, but as it is not, I think this is just inviting people to write error-prone code as partially initialized templates cannot be differentiated from fully initialized ones. They would not get any feedback from tools that the template they use is not fully initialized (even though in most cases, this is probably unintentional) and then can run into situations at runtime where there is an error because they are using the template (which is often expensive).
Therefore, I would either go into the direction of specifically having to declare a template as abstract/partial or whatever or to forbid this entirely (which doesn't hurt as one can always use wildcards to fill in the abstract holes).

(0011597)
Jacob Wieland - Spirent
26-08-2013 14:53

Also, the restriction exists that all operaands (except certain exceptions) to predefined functions (here: match) must be fully initialized. Therefore, the match({ field1 := 1, field2 := - }, t_r); would also produce an error.

(0011713)
Gyorgy Rethy
08-10-2013 18:00

I have checked the text of the standard and found:
1. There is _no_ requirement saying that constants should be completely initialized. The same apply for module parameters and templates. For templates it is explicitly stated that they need to be completely initialized, when used in a send or receive operation: i.e. implicitly confirmed that may not be initialized in before. Records, sets and unions may even be left uninitialized by using {} at the RHS of their declarations.
2. For expressions it is stated that only the _operands_ of operators has to be initialized: i.e. it is allowed to assign partially initialized objects and consequently also allowed to pass them as actual parameters (btw. this is stated explicitly for variables).
3. Except for the listed exceptions, in and inout _parameters_ of predefined functions shall completely be initialized. Hence match({field1:= 1,field2:=-}, t_r); shall cause an error.
We cannot make non-backward compatible changes in the standard. In addition, using partially initialized constants/templates have use cases: for example, used as global values/templates to initialize dynamically built messages; in this case, leaving the dynamically assigned fields uninitialized will prevent sending a wrong message, when a field of the message is forgotten to be completed runtime (otherwise a dummy value would have to be used when initializing the constant/template and the message would be sent containing this dummy value - causing a debugging nightmare for the user).
Therefore, I agree with Tomas, we need to define the rules of using not or partly initialized stuff in general, not only for variables. I will prepare a proposed draft.

(0011728)
Jacob Wieland - Spirent
09-10-2013 12:27

I have to reiterate. What shall be the purpose of not-fully-initialized constants or module parameters which can never become fully initialized and therefore are basically just potential error-carriers? What is the use-case?
For templates, even though I still see them as problematic for the same reason, I can see the argument that they can be used as the basis for modification (and in that way - "changed") later on.

(0011730)
Tomas Urban
09-10-2013 13:15

Just one slightly off-topic note. It was mentioned several times in this thread that match is a predefined function. That's an incorrect statement. Match doesn't belong to predefined functions and it is not an operand of an expression either. The core language specification defines it as an operation. As such, limitations on predefined function parameters and operands of expressions cannot be applied to it.
The point of this CR is that while the core language specification has a rule on using partially initialized variables, other entities are not affected by this rule. And the fact is that regardless whether some of these entities are practically usefull or not, they do not produce the same kind of behaviour as variables even if the content is the same. Therefore I believe, that extending the rule currently valid for variables only to all values regardless of their origin would make the specification better.
The question whether partially initialized static content is fine shall be handled separately in a different CR.

(0011737)
Gyorgy Rethy
09-10-2013 17:11 (edited on: 09-10-2013 17:18)

copy-paste:
"using partially initialized constants/templates have use cases: for example, used as global values/templates to initialize dynamically built messages; in this case, leaving the dynamically assigned fields uninitialized will prevent sending a wrong message, when a field of the message is forgotten to be completed runtime (otherwise a dummy value would have to be used when initializing the constant/template and the message would be sent containing this dummy value - causing a debugging nightmare for the user)."
And again, unless we can _guarantee_ that a functionality is unused, we cannot make a non-backward compatible change. This statement was reinforced several times from TF160, from our users and from TC MTS. I would like to avoid going to MTS with a minor issue like this.

(0011738)
Gyorgy Rethy
09-10-2013 17:12 (edited on: 09-10-2013 18:12)

TomaÅ¡, thank for noting the match operation, I will look after it as well.

(0011740)
Gyorgy Rethy
10-10-2013 08:49

See draft resolution text for review in CR6430_resolution_v1.doc.

(0011741)
Gyorgy Rethy
10-10-2013 08:56

It needs be discussed in the STF, how to continue with this CR.

(0011749)
Jacob Wieland - Spirent
10-10-2013 13:03

The addenda to constants and templates regarding the partial initialization are unnecessary/superfluous as this is already covered by the definition of partially initialized.
For module parameters, it should only be necessary that they are at least partially initialized upon USAGE. The initialization state of unused module parameters should not be of any consequence.
The backward compatibility issue regarding standardization bodies I don't see as that problematic in this case as at least one tool does not support partially initialized templates (not template variables!), constants and module parameters. Since no standardization body (and at least none of our customers) has yet complained about this being a missing feature in the tool, I surely think this would be more on the level of a clarification than an actual backward-incompatible change that would have any real negative impact.
But, if you insist that you need this feature, do the clarification in the other direction.

(0011750)
Jacob Wieland - Spirent
10-10-2013 13:08

In principle, I agree with the proposal originally given in the CR description that the restriction at the moment given only for value variables and template variables shall be enlarged to all values and templates. Then, we would not have to repeat that restriction over and over again.

(0011760)
Gyorgy Rethy
10-10-2013 17:27 (edited on: 10-10-2013 17:47)

STF decisions on 10-10-2013:
- the restriction shall not be related to WHAT we use but to WHERE we use it; namely, the restrictions of 11.1 e) and 11.2 e) shall be moved to the relevant clauses (actual parameters, assignment, function return, rotate, concatenation match etc.), thus making them valid for all kind of data objects;
- definition of partially initialized, note 2 shall not make a distinction between constant/templates/modulepars vs. variables but be valid for all type of data objects;
- in general, already initialized objects shall not be allowed to be made uninitialized.

(0011761)
Gyorgy Rethy
10-10-2013 17:46

Pls. see CR6430_resolution_v2.doc, changed acc. to the decisions below.

(0011769)
Jacob Wieland - Spirent
11-10-2013 12:24 (edited on: 11-10-2013 12:26)

I still think that 8.2.1. restriction h) is wrong. It would enforce that all module parameters need to be initialized (partially), even the unused ones. When all places that use things explicitly forbid the usage of uninitialized module parameters, then this is completely sufficient to catch errors caused by uninitialized module parameters.
Of course,the same is true for constants and templates. The error would simply be caused by the usage, not by the declaration.

(0011771)
Jacob Wieland - Spirent
11-10-2013 12:29

Also, we dropped this requirement for STF160 that for return, the returned data object must be partially initialized. So, this has to be removed as well.

(0011772)
Jacob Wieland - Spirent
11-10-2013 12:30

please see my previous notes

(0011784)
Gyorgy Rethy
11-10-2013 14:41

I agree with all your comments, they have been implemented. See and review CR6430_resolution_v3.doc.

(0011793)
Jacob Wieland - Spirent
11-10-2013 16:33

okay with me

(0011853)
Ina Schieferdecker
28-11-2013 10:56

as proposed with small editorials in v4