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

ID | Project | Category | View Status | Date Submitted | Last Update
0005922 | Part 01: TTCN-3 Core Language | Technical | public | 22-08-2011 15:19 | 28-08-2013 14:58

Reporter | Andrus Lehtmets |
Assigned To | Ina Schieferdecker |
Priority | normal | Severity | major | 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) | TTCN-3 Edition 4.3.1: Core Language
Source (company - Author) | Elvior

Summary | 0005922: why strong typing is not used in map and unmap?
Description | Why strong typing is not used in map and unmap This makes it impossible to resolve system type during compile time. This is important when using port parameters, because otherwise it is impossible to perform any compile time check regarding parameter types an number of parameters.
Steps To Reproduce |

Additional Information

Ina: Wrt. strong typing in map: we have the concept of consistent connections in TTCN-3, which also apply to the usage of map and unmap. That has been designed by intend. Please explain scenarios why (and how) you like to sharpen this.
TomÃ¡Å¡ Urban: The problem is that TSI type declaration is a part of test case declaration and it is visible only within its scope. So if you use map(self:PCO2, system:PCO1) param(v_test1, v_test2) inside a function called from the test case (which is a common situation in many test suites), there's no way how to find out what is the system port type in compile time and it is therefore necessary to link parameters in runtime. We have no technical issues with implementing this solution, but it means that some errors in the code won't be discovered during compilation. Strong typing would resolve this problem. It could be applied only if the param clause is present (meaning there would be no backward compatibility problems with legacy mapping/unmapping calls which don't contain parameters) and it would determine the required type of the system port: map(self:PCO2, system:PCO1) param MyPortType (v_test1, v_test2).

Tags | No tags attached.

Relationships

related to | 0006412 | closed | Ina Schieferdecker | system component shall be passed to functions with map/unmap statements

Attached Files | CR5922.doc (753,664) 29-09-2011 14:10 http://oldforge.etsi.org/mantis/file_download.php?file_id=2574&type=bug CR5922-v2.doc (1,268,736) 11-07-2013 15:21 http://oldforge.etsi.org/mantis/file_download.php?file_id=2831&type=bug CR5922-v3.doc (1,292,800) 28-08-2013 14:57 http://oldforge.etsi.org/mantis/file_download.php?file_id=2870&type=bug

Issue History
Date Modified | Username | Field | Change
22-08-2011 15:19 | Andrus Lehtmets | New Issue |
22-08-2011 15:19 | Andrus Lehtmets | Clause Reference(s) | => TTCN-3 Edition 4.3.1: Core Language
22-08-2011 15:19 | Andrus Lehtmets | Source (company - Author) | => Elvior
27-09-2011 12:09 | Gyorgy Rethy | Project | TTCN-3 Change Requests => Part 01: TTCN-3 Core Language
27-09-2011 12:09 | Gyorgy Rethy | Assigned To | => Jacob Wieland - Spirent
27-09-2011 12:09 | Gyorgy Rethy | Status | new => assigned
27-09-2011 12:09 | Gyorgy Rethy | Target Version | => Edition 4.4.1
27-09-2011 16:37 | Jacob Wieland - Spirent | Note Added: 0010254 |
29-09-2011 10:50 | Gyorgy Rethy | Note Added: 0010292 |
29-09-2011 14:10 | Jacob Wieland - Spirent | File Added: CR5922.doc |
29-09-2011 14:11 | Jacob Wieland - Spirent | Note Added: 0010299 |
29-09-2011 14:11 | Jacob Wieland - Spirent | Assigned To | Jacob Wieland - Spirent => Gyorgy Rethy
30-11-2011 11:16 | Gyorgy Rethy | Note Added: 0010437 |
30-11-2011 11:16 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
02-12-2011 09:04 | Jens Grabowski | Note Added: 0010498 |
02-12-2011 09:05 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
02-12-2011 14:02 | Gyorgy Rethy | Note Added: 0010526 |
02-12-2011 14:02 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
06-12-2011 10:12 | Jacob Wieland - Spirent | Note Added: 0010531 |
16-12-2011 05:21 | Ina Schieferdecker | Note Added: 0010539 |
16-12-2011 05:22 | Ina Schieferdecker | Target Version | Edition 4.4.1 => v4.7.1 (published 2015-06)
11-07-2012 16:21 | Jens Grabowski | Note Added: 0010843 |
11-07-2012 16:22 | Jens Grabowski | Assigned To | Jens Grabowski => Gyorgy Rethy
13-07-2012 11:55 | Gyorgy Rethy | Note Added: 0010916 |
13-07-2012 14:43 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Jens Grabowski
13-07-2012 15:46 | Tomas Urban | Note Added: 0010934 |
16-07-2012 10:35 | Jacob Wieland - Spirent | Note Added: 0010936 |
16-07-2012 10:50 | Jacob Wieland - Spirent | Note Edited: 0010936 |
18-01-2013 11:44 | Jacob Wieland - Spirent | Relationship added | related to 0006412
08-07-2013 18:20 | Gyorgy Rethy | Target Version | v4.5.1 (published 2013-04) => v4.6.1 (published 2014-06)
09-07-2013 11:35 | Jacob Wieland - Spirent | Note Added: 0011456 |
11-07-2013 15:21 | Jacob Wieland - Spirent | File Added: CR5922-v2.doc |
11-07-2013 15:22 | Jacob Wieland - Spirent | Note Added: 0011549 |
11-07-2013 15:22 | Jacob Wieland - Spirent | Assigned To | Jens Grabowski => Ina Schieferdecker
11-07-2013 15:22 | Jacob Wieland - Spirent | Status | assigned => confirmed
28-08-2013 14:57 | Ina Schieferdecker | File Added: CR5922-v3.doc |
28-08-2013 14:57 | Ina Schieferdecker | Note Added: 0011625 |
28-08-2013 14:57 | Ina Schieferdecker | Status | confirmed => resolved
28-08-2013 14:57 | Ina Schieferdecker | Resolution | open => fixed
28-08-2013 14:57 | Ina Schieferdecker | Fixed in Version | => v4.6.1 (published 2014-06)
28-08-2013 14:57 | Ina Schieferdecker | Status | resolved => closed

Notes

(0010254)
Jacob Wieland - Spirent
27-09-2011 16:37

I propose the following solution.
1) disallow parameterized map/unmap for unknown mtc/system-ports.
2) - allow system clauses also on function/altstep definitions (where system compatibility must be the same as runs on compatibility)
- allow mtc clauses (analogously to system clauses) for function/altstep definitions (where mtc compatibility must also be the same as runs on compatibility)
For backward compatibility, it shall still be allowed to call a function/altstep without system/mtc clause from a context with system/mtc clause, as long as the restrictions on the runs on compatiblity are adhered to.
Like for runs-on clauses, it shall not be possible to call a function/altstep with a system/mtc clause from a context without system/mtc clause (respectively).

(0010292)
Gyorgy Rethy
29-09-2011 10:50

STF discussion 2011-09-29: proposal is basically agreed; map operation using parameters shall use the system keyword.

(0010299)
Jacob Wieland - Spirent
29-09-2011 14:11

uploaded proposal, please review

(0010437)
Gyorgy Rethy
30-11-2011 11:16

Jens, pls. review.

(0010498)
Jens Grabowski
02-12-2011 09:04

Proposal looks good for me. However, I am not sure about backwards compatability. The additional restrictions may invalid older test suites. GyÃ¶rgy, please have a look at this.

(0010526)
Gyorgy Rethy
02-12-2011 14:02

I may be biased by the earlier discussions that the whole mtc and system checking stuff shall be an option to the user. I.e. it shall be able to introduce it with minimal effort into its code and no checking shall be mandatory. From the proposed text only the additional restrictions to the
16.1.1 Invoking functions
and
16.2.1 Invoking altsteps
clauses seem to be potentially problematic as they can also be understood that these checks are always mandatory (while they are mandatory for the tools only IF any of these clauses present).
I'm, still not quite sure about the practical usability of these additions. They become absolutely useless as soon as the user has two MTC or two TSI types with the same port instance definition(s). In this case he/she cannot use the mtc clause e.g. in activated defaults that will check the messages on that common port instance(s).

(0010531)
Jacob Wieland - Spirent
06-12-2011 10:12

I don't understand the objection/doubts. If two component types have the same instance definitions, then they are compatible and so don't pose a problem when checking.
The additional restrictions have been modeled after the existing ones for the runs-on clause so they are consistent with the already existing features and totally backward compatible. If code does not use system/mtc clauses it is as valid as before. Only if the new map-param-statement shall be used do they get any relevance.
In principle, this will only lead to a very meagre number of new system/mtc clauses, i.e. only those functions need it that use these map statements (which are normally called directly from the testcase where mtc and system type are known anyway) need them.

(0010539)
Ina Schieferdecker
16-12-2011 05:21

Since resolution is not yet agreed, it is moved to 2012

(0010843)
Jens Grabowski
11-07-2012 16:21

GyÃ¶rgy, please check the comments from Jacob.

(0010916)
Gyorgy Rethy
13-07-2012 11:55

I think that the proposal is too restrictive. The component type in the mtc and system clauses would be used to check only the port consistency in map operations when mtc nad/or system ports are mapped. But in this case:
1) Why ALL definitions shall be compatible for mtc and system component compatibility? (clause 6.3.3 item 3) and 4)) Why it is not sufficient if port definitions are compatible?
2) Why a function or altstep with an mtc and/or a system clause cannot be called from a function or altstep without mtc or system clause? The feature provided by mtc and system clauses
- is local to the map operation
- is totally different from the runs on clause; runs on identifies a component type on which the given function should run. While an mtc clause identifies a "foreign" component, the given function is just references a port of it. In case of system, even no TTCN-3 code is running on TSI. So, trying to compare mtc and system clauses to runs on clauses is the same as comparing apples with avocado: they are simply different things.
So, I don't understand, why the simple example below should be disallowed?:
function f() runs on PTC {// why mtc and system clauses would be needed here, when they are not used to anything?
var PTC v_PTC := PTC.create;
makeMaps();
makeConnections(v_PTC)
}
function makeMaps() runs on PTC mtc MTC system TSI {
map (mtc:P, system:P)//the mtc and system clauses are needed only to check this statement
}
function makeConnections(PTC p_PTC ) runs on PTC mtc MTC {
connect (p_PTC:COORD, mtc:COORD); //the mtc clause is used only to check this statement
}
From a practical perspective, the restrictive approach is useless, because no user (no Ericsson user) will be able or will want to introduce mtc and system clauses throughout the WHOLE existing code, practically for nothing; while, if mtc and system clauses would be required only at the places, where they are REALLY needed, the feature would be used!

(0010934)
Tomas Urban
13-07-2012 15:46

I agree with GyÃ¶rgy. I would prefer if it was still possible to call functions with mtc and system clause from functions that don't contain these clauses. Of course if both caller and callee contain the clauses then compatibility check should be still performed.

(0010936)
Jacob Wieland - Spirent
16-07-2012 10:35 (edited on: 16-07-2012 10:50)

What you propose would negate anything to be gained from the new construct, i.e. being able to check statically, whether a map statement will be semantically correct at runtime or not. If a function is called from a context which does not know its system type, then no static analysis can determine if the system type required by the calling function (via system clause) is compatible with the one in the runtime context of the calling one, i.e. if the ports to be mapped to actually exist and have the right attributes.
So, the restrictions I proposed are SPECIFICALLY designed to grant exactly this possibility - to allow static correctness analysis of map statements outside of testcase definitions (i.e. in functions or altsteps).
Also, the scenario that Gyorgy describes Ericsson would be faced with is totally unrealistic. Only those functions that directly or indirectly use a map statement (like the function f() in your example which incidentally DOES use a map statement, albeit indirectly) need to be augmented with the system clause (all others need not be changed at all) - which should be very few.
The rules are simple. If a function causes a map statement, then it should ensure its correctness. If a function causes a connect statement, then it should ensure its correctness.
In principle, I could live with lessening the restriction - thus yielding a warning during static analysis like today if the system type of the calling function is unknown or cannot be safely determined -, but then for consistency reasons, it should be lessened for the runs on clause as well, as there the same arguments can be used, i.e. that runtime checks are totally sufficient (for some people).
Finally, the argument about the restrictions regarding non-ports is totally academic, as using a full-fledged component type as system type does not make sense (and therefore is a misleading use of a type) as the system has no behaviour that could access its timers/variables/constants (and they cannot be accessed by anyone else either). To alleviate the fears of possible backward incompatibilities of such strange usages, the restrictions between system clauses could, of course, be limited to the port declarations only.

(0011456)
Jacob Wieland - Spirent
09-07-2013 11:35

Shall this be further discussed?
Summing up the concerns:
- define mtc/system compatibility only regarding to port declarations
- allow clause-less behavior to call clause-having behavior even though this can lead to runtime errors
For consistency's sake, I would propose to have the same lessing of presence-of-clause-restriction for the runs-on clause as otherwise no user will ever understand why the restriction is (unnecessarily) enforced in one place but not in the others which to them are very much alike.

(0011549)
Jacob Wieland - Spirent
11-07-2013 15:22

please check

(0011625)
Ina Schieferdecker
28-08-2013 14:57

Implemented with editorial corrections