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

ID | Project | Category | View Status | Date Submitted | Last Update
0006698 | Part 01: TTCN-3 Core Language | New Feature | public | 06-03-2014 10:58 | 19-06-2014 17:11

Reporter | Wolfgang Seka |
Assigned To | Tomas Urban |
Priority | urgent | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | won't fix |
Platform |  | OS |  | OS Version |
Product Version | v4.6.1 (published 2014-06) |
Target Version | v4.6.2 (interim 2014) | Fixed in Version | v4.6.2 (interim 2014) |
Clause Reference(s) | ES 201 873-1 15.10
Source (company - Author) | MCC160 - Wolfgang

Summary | 0006698: Missing functionality to cast "template" to "template (present)"
Description | With valueof a template (especially with restriction "template (omit)" can be casted to a value (what serves "template (value)" as well). But there is no way make a "template (present)" out of a "template" in case it is know that the template is present.
Steps To Reproduce |
Additional Information | This issue is related to 6697
Tags | No tags attached.
Relationships |
Attached Files |

Issue History
Date Modified | Username | Field | Change
06-03-2014 10:58 | Wolfgang Seka | New Issue |
08-04-2014 08:58 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
08-04-2014 09:32 | Gyorgy Rethy | Assigned To | => Tomas Urban
08-04-2014 09:32 | Gyorgy Rethy | Status | new => assigned
08-04-2014 09:32 | Gyorgy Rethy | Product Version | => v4.6.1 (published 2014-06)
08-04-2014 09:32 | Gyorgy Rethy | Target Version | => v4.7.1 (published 2015-06)
08-04-2014 09:36 | Gyorgy Rethy | Note Added: 0011949 |
08-04-2014 13:37 | Tomas Urban | Note Added: 0011959 |
08-04-2014 15:35 | Wolfgang Seka | Note Added: 0011962 |
08-04-2014 17:01 | Tomas Urban | Note Added: 0011964 |
09-04-2014 09:45 | Wolfgang Seka | Note Added: 0011966 |
09-04-2014 11:35 | Jacob Wieland - Spirent | Note Added: 0011970 |
09-04-2014 12:35 | Gyorgy Rethy | Priority | normal => urgent
10-04-2014 09:41 | Gyorgy Rethy | Note Added: 0011984 |
10-04-2014 09:42 | Gyorgy Rethy | Priority | urgent => normal
17-06-2014 09:57 | Gyorgy Rethy | Priority | normal => urgent
17-06-2014 10:55 | Gyorgy Rethy | Note Added: 0012099 |
17-06-2014 15:03 | Tomas Urban | Note Added: 0012108 |
17-06-2014 15:56 | Gyorgy Rethy | Target Version | v4.7.1 (published 2015-06) => v4.6.2 (interim 2014)
17-06-2014 16:59 | Wolfgang Seka | Note Added: 0012112 |
18-06-2014 07:58 | Tomas Urban | Note Added: 0012114 |
18-06-2014 08:21 | Wolfgang Seka | Note Added: 0012116 |
18-06-2014 14:19 | Tomas Urban | Note Added: 0012128 |
18-06-2014 16:37 | Wolfgang Seka | Note Added: 0012133 |
19-06-2014 15:25 | Gyorgy Rethy | Note Added: 0012151 |
19-06-2014 15:27 | Gyorgy Rethy | Note Edited: 0012151 | bug_revision_view_page.php?bugnote_id=12151#r45
19-06-2014 15:30 | Gyorgy Rethy | Status | assigned => closed
19-06-2014 15:30 | Gyorgy Rethy | Resolution | open => won't fix
19-06-2014 15:30 | Gyorgy Rethy | Fixed in Version | => v4.6.2 (interim 2014)
19-06-2014 15:32 | Gyorgy Rethy | Note Edited: 0012151 | bug_revision_view_page.php?bugnote_id=12151#r46

Notes

(0011949)
Gyorgy Rethy
08-04-2014 09:36

The purpose and the expected functionality to be clarified with Wolfgang.

(0011959)
Tomas Urban
08-04-2014 13:37

Assigning from an unrestricted template to a restricted one is allowed and should not cause any problem if all restriction requirements are met. No casting operation (similar to valueof) is necessary in this case. So e.g. the following code should work without a problem:
type record R {
integer field1,
integer field2
}
...
var template R vm_unrestricted := {
field1 := (0..10),
field2 := ?
}
var template(present) R vm_present := vm_unrestricted;
Could you please provide a code example that causes problems? Or would you like to have an similar example as above or a note explaining this functionality in the core language specification?

(0011962)
Wolfgang Seka
08-04-2014 15:35

This would an improvement:
when we have e.g.
template (present) SomeType cr_AnyTemplate := { ... };
function f_MyFunction(template SomeType p_AnyOrOmitTemplate)
{
var template (present) SomeType v_AnyTemplate;
if (ispresent(p_AnyOrOmitTemplate)) {
v_AnyTemplate := p_AnyOrOmitTemplate;
} else {
v_AnyTemplate := cr_AnyTemplate;
}
...
}
currently at least one compiler raises a warning because of the potential risk of a runtime error. In general I appreciate that kind of warning as sometimes it really helps to correct issues in the implementation.
But in cases like above (and we have several of them) we always need to check that the code is correct as it is. Therefore - and for completeness - we would consider it as improvement when we can explicitly says "we know what we are doing - we have checked that the template is really there" so that we don't get warnings anymore (but we still get warnings in cases where it is unintended)

(0011964)
Tomas Urban
08-04-2014 17:01

The current position of the STF 478 is that it would not be very efficient if the TTCN-3 language standard provided a standardized (casting) solution for each situation where TTCN-3 tools might generate a warning. It would make the language even more complicated than it is right now. The valueof operand is an exception to this rule, because conversion from values to template is necessary as certain operations are not permitted for templates.
However, it would be possible to introduce a generic solution for suppressing warnings, e.g. in the following statement. We were thinking of a special comment format, but it might have other form (that will be decided in further discussion). But before we go on with that, we would like to know your opinion. In your case the code would look like:
function f_MyFunction(template SomeType p_AnyOrOmitTemplate)
{
var template (present) SomeType v_AnyTemplate;
if (ispresent(p_AnyOrOmitTemplate)) {
//@nowarn
v_AnyTemplate := p_AnyOrOmitTemplate;
} else {
v_AnyTemplate := cr_AnyTemplate;
}
...
}

(0011966)
Wolfgang Seka
09-04-2014 09:45

I have no strong opinion about whether or not it is efficient to cast less restricted templates to stronger restricted ones - even though it would enable tools give better information a compile time. That "@nowarn" pragma could be an option ... But - where to place it: intuitively I would expect it in that line for which no warning shall be issues. But that is different from your example.

(0011970)
Jacob Wieland - Spirent
09-04-2014 11:35

Testing Tech agrees that this would be a very useful feature. We actually were thinking about raising the same CR (something like presentof()). Of course, the nowarn annotations could also be a way to reduce the number of warnings. Still another way to go would be an explicit cast operator which could be useful in multiple occasions of such problems.

(0011984)
Gyorgy Rethy
10-04-2014 09:41

STF discussion: should not go into the interim version. The real value and implications of a cast operation to be clarified.

(0012099)
Gyorgy Rethy
17-06-2014 10:55

STF discussion:
- warning control should be at the tool level; putting it into the language could spoil readability; warning control could be put into tool-specific extension attributes
examples:
function f() {v_AnyTemplate := v_AnyOrOmitTemplate} with { extension "nowarning" }
function f() {
v_AnyTemplate := v_AnyOrOmitTemplate;
{v_AnyTemplate1 := v_AnyOrOmitTemplate1} with { extension "warning" }
} with { extension "nowarning" }

(0012108)
Tomas Urban
17-06-2014 15:03

Wolfgang, the conclusion we have reached so far is that it is rather a tool issue than a TTCN-3 language problem and it should be discussed on the 3GPP meeting with tool vendors. As the TTCN-3 language standard doesn't require or recommend to generate a warning in the described case, it is not possible to define a mechanism that would suppress such a warning. In the previous György's comment, you can find a possible solution of TTCN-3 complient (but still tool-dependent) warning suppression mechanism.
Could you please inform us if such a solution is suitable for you so that we can close the CR? Of course, if the proposal is not fine with you, please send us your objections.

(0012112)
Wolfgang Seka
17-06-2014 16:59

I'm happy with György's proposal but wonder how it can be specified to be common for all tools:
I assume when a tool does not understand the extension it shall just ignore it;
but when a tool supports suppression of warnings somehow it shall be standardised that "warning"/"nowarning" are at least one common way to control warnings from within TTCN-3.
What we definitely don't want is that different tools require different extensions.

(0012114)
Tomas Urban
18-06-2014 07:58

Unknown extensions should be indeed ignored by the TTCN-3 tools. If you wish to have a standardized solution for your project, I think the easiest way is to describe all necessary extensions in your project requirements and discuss support questions with representatives of tool vendors.

(0012116)
Wolfgang Seka
18-06-2014 08:21

"... describe all necessary extensions in your project requirements and discuss support questions with representatives of tool vendors"
That is exactly what I'm not happy with: We don't want to have a project or tool vendor specific solution for this case.
Please note that I'm still not convinced that this is not a language issue; nevertheless I could live with a solution on tool level when it is standardised.

(0012128)
Tomas Urban
18-06-2014 14:19

I see. We can specify a standardized solution for you, but I am not sure if we can publish it as a part of TTCN-3 standards. Would an unpublished, i.e. not binding specification be enough for you or would you prefer an extension package?

(0012133)
Wolfgang Seka
18-06-2014 16:37

After some internal discussion with Olivier we have the common opinion that there shall be some official specification, e.g. for standard extensions.
These standard extensions can be put to some annex. Personally I think that it is sufficient to keep that informative but it would make clear for all tools and projects that when a tool supports suppression of warnings how this has to be expressed in TTCN.

(0012151)
Gyorgy Rethy
19-06-2014 15:25 (edited on: 19-06-2014 15:32)

STF decision: STF cannot decide to produce a new part of TTCN-3 (extension package) on its own, TC MTS shall approve a NWI for this. In the STF's oppinion it should be an EG or TR document, rather than an extension package. We can report the outcome of this CR to TC MTS, but we cannot propose the NWI.